September/October 2018 issue of acmqueue The September/October issue of acmqueue is out now

Subscribers and ACM Professional members login here


  Download PDF version of this article PDF

Error 526 Ray ID: 488aeb30b921c5de • 2018-12-13 19:43:16 UTC

Invalid SSL certificate








What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.


Originally published in Queue vol. 9, no. 11
see this item in the ACM Digital Library



Alpha Lam - Using Remote Cache Service for Bazel
Save time by sharing and reusing build and test output

Jez Humble - Continuous Delivery Sounds Great, but Will It Work Here?
It's not magic, it just requires continuous, daily improvement at all levels.

Nicole Forsgren, Mik Kersten - DevOps Metrics
Your biggest mistake might be collecting the wrong data.

Alvaro Videla - Metaphors We Compute By
Code is a story that explains how to solve a particular problem.


(newest first)

Displaying 10 most recent comments. Read the full list here

queue | Fri, 23 Oct 2015 05:08:47 UTC

/* Better version of Figure 12 routine? (read in fixed-sized courier font) */

#include // For std::string. #include // For std::vector.

/****************************************************************************** PURPOSE: tokenize - Parse string into tokens using delimiter. INPUTS: const std::string& input String to parse. const std::string& delimiter String that separates tokens. OUTPUTS: std::vector& tokens Sequence of tokens. ******************************************************************************/

void tokenize( const std::string& input, std::vector& tokens, const std::string& delimiter = " " ) {

const size_t input_length = input.length(); const size_t delimiter_length = delimiter.length();


if ( input_length && delimiter ) ) {

if ( delimiter_length == 0 ) { tokens.push_back( input ); //x } else { size_t start_index = 0;

do { const size_t end_index = input.find( delimiter, start_index ); std::string token;

if ( end_index == std::string::npos ) { token = input.substr( start_index ); start_index = end_index; // Stop looping. } else { const size_t length = end_index - start_index; token = input.substr( start_index, length ); start_index = end_index + delimiter_length; }

if ( token.length() ) { tokens.push_back( token ); //x }

} while ( start_index < input_length ); } } }

Ron Burk | Sat, 03 Mar 2012 17:37:55 UTC

Choice of IDE is what makes code "clear, maintainable, and understandable"? That's rather like saying that museum lighting is what makes the Mona Lisa a great work of art. A very puzzling claim.

Kevin Wall | Mon, 28 Nov 2011 22:23:07 UTC

Correctness is more important code that is readable. In Example 1, it is doubtful that the code is correct. I suspect that what you intended was to allow either upper or lower case characters for each command, but in reality, you only did this for the first ('q' vs. 'Q') command. If that was not the intent, the superfluous "case" statements should be eliminated.

Roger Ellman | Wed, 16 Nov 2011 11:57:01 UTC

How pleasurable to see that good code parallels good design. Clean, clear and user-friendly!


John Harriott | Wed, 16 Nov 2011 11:02:31 UTC

Firstly. Whatever style is used why not pick an IDE that automatically formats the code to a consistent style. Why spend valuable time inserting whitespace to align tokens, when that time could be spent writing real code?

Secondly. I suggest the authors read Robert Martins book "Clean Code", it's gold!!! I used to code in style that is discouraged by the book. But after reading the book I no longer write code that way any more. If methods are small, have a consistent level of abstraction and use intention revealing identifiers, the need for whitespace and other formatting is irrelevant IMHO.

doug65536 | Fri, 11 Nov 2011 11:01:51 UTC

While this seems well intentioned, imposing arbitrary rules like this too strictly only serves to annoy programmers, making their work feel less like a passion and more like they are living in a dictatorship. I've had to work under code formatting dictatorship and I resented it. I felt as though non-developers were dictating that the source code look a certain way with no benefit that I could see other than to make me have to pick at the code to make it look a way that I didn't like. It causes you to lose delicate mental context, instead of being able to focus on what you're really doing, implementing an algorithm.

In my opinion, the more deterministic the style, the better. I've always hated programmers indenting parameter declarations to be aligned with the opening parenthesis. It's completely non-deterministic, and you wind up with people spending extra time picking at the whitespace and playing around fixing the indentation to some arbitrary "policy" that causes you to lose context and spend mental cycles on something pretty much irrelevant.

The ruler with which I measure a formatting style: can you write a script that could perform the formatting? Would it require a lot of special cases? Would it require you to maintain a lot of context and backtrack? If so, then it's a bad style. The simpler it is, the less it wipes your mental context.

Too much emphasis is put on making it "easier to read" by someone else. Can they read code or can't they? Some arbitrary strict whitespace policy doesn't make it enough easier to make any significant difference.

I think the only strict rule that should be imposed is not allowing excessively long lines. You should NEVER have to scroll horizontally.

Tim Comber | Fri, 11 Nov 2011 00:29:07 UTC

No mention of abbreviations? I do not let my students use abbreviations for a number of reasons: * Cognitive load - unless an abbreviation is very familiar it takes time and effort to work out what the abbreviation means. * How much harder is it to write 'number' than 'num'? Does two more letters really make a variable too long? * Your abbreviation is not necessarily my abbreviation. This is especially important when teaching students as they are quite happy to write 'nuAccount', 'numbAccount', 'nAccount' etc. They do not know that 'num' is a common programming abbreviation. Why teach them new words when there is a perfectly good English word already available. * I believe it is better to base names on the language used in the domain of interest. If accountants use Account Number when talking about accounts then the variable should be AccountNumber not AccountNum.

Ed Kimball | Thu, 10 Nov 2011 15:29:41 UTC

@fileoffset -- you may prefer to read YOUR code as a book, but how would you prefer to read someone else's code. As someone looking at the code for the first time and trying to understand it, I find figure 2 vastly inferior to figures 1 and 3.

BTW, the function getBalance in figure 6 violates the principles stated with figure 4. Since the function returns a value without changing any arguments, its name should be a noun or noun phrase, like CurrBal or CurrentBalance, according to figure 4.

Pat LaVarre | Mon, 07 Nov 2011 22:31:43 UTC

@aligned as a table:

The Opposition to spacing code out like a table includes the Python Style of that explicitly discourages "more than one space around an assignment (or other) operator to align it with another".

I think me, when working mostly with people who won't teach their tools to maintain vertically-aligned tabulation for us, I give up, write one blank instead of many, and then tabulate the code in my head on the fly as I read it.

I do remember seeing work-groups educated in the mainframe-not-mini culture of tabulating more often go and agree on everyone using editors that treated any string of two and more blanks as a division between one column of text and the next. Then when you edited the value of a cell of the table, the blank text to the right of it could shrink as far as two blanks to keep the remaining cells of the row in place.

I've not seen that parsing rule duplicated in wikitexts, instead I see people make columnar divisions explicit with a quiet | that wouldn't fit in code, or a loud /*|*/, never by making the width of whitespace significant.

paulsj | Mon, 07 Nov 2011 14:54:33 UTC

Also - statement "code is beautiful because its constant definitions are aligned as a table" is equivalent to statement "painting is nice, I like form of the frame". IMHO code just reflects beauty of thought, and is too subtle to put it in standards (compare it with sense of humour), also because it cannot be viewed outside of context.

Displaying 10 most recent comments. Read the full list here
Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.