Comment by nostrademons | Hacker News Reader

Comment by nostrademons | Hacker News Reader

A lot of the practices here are enshrined in the Google C++ styleguide:

http://google-styleguide.googlecode.com/svn/trunk/cppguide.x...

The author's first point about establishing conventions so that you can re-use the code that works with those conventions is very important. At Google, nobody writes code to serialize/deserialize bytes, because the default answer is just "use protobufs". Nobody writes low-level communication protocols (well, outside of some very-specialized infrastructure teams), because there's one RPC system. There's one standardized naming system, and a mostly-standard logs format and method for analyzing logs. If you do batch computation, there're two solutions, and there're only a handful of different file formats and storage engines, certainly less than in the open-source world.

I think Rails and Django (and Lisp) discovered the same principle: if you get everybody writing their code & data files the same way, you can write tools to manipulate those files, and that saves you way more in productivity than trying to get the perfect file format.

Autotest: pickles over ssh stdin/stdout. They would have also had base64-encoded pickles in mdb labels if I hadn't stopped them. Or who knows, maybe they went through with it with me out of the way.

Logjammer/Treehorn: XMLRPC. (Yes, what a horrible project name. Juveniles.)

There are others. NIH actually happens inside the company too.

> A lot of the practices here are enshrined in the Google C++ styleguide:

with the notable exception of lining up things horizontally, which tends to be frowned on.

I really do not understand why they chose to do so. In my opinion, it does not improve readability at all, even worse, when the spacing between type and name gets big, your eyes need more work to figure out the correct line relations.

Furthermore, this can generate horrible commits, for example:

  int x;
  int y;

becomes:

  int   x;
  int   y;
  float z;

after adding ONE single variable. But your commit will contain changes for the above 2 lines. This will make for an insane experience once your variable list grows to a certain size (including multiple spacing changes) and you intend to rollback/cherry-pick/time-warp. Then you will get to deal with the full wrath of conflict resolution. Also, your commit (of one logical line change) contains way to much meta info, which also decreases commit/diff readability.

I do that, and I don't find it to be that much of an issue, myself. In my experience, it's rare that I add a new variable to a funtion, so I guess your mileage may vary.

If trivial whitespace difference causes wrath fill conflicts then I think you have a deeper issue. I can't think of a situation where this would be even a minor issue.

Not a huge deal, but it hides the actual author of that line when you're doing a blame. I try to only change the precise lines I need to in a commit, and all of them are relevant to the commit message. That way it's usually a very quick check to see what commit added a certain line.

If I absolutely need to do some tidying in a file, I do it in a fully separate commit so that the change can not be construed to be related to the other feature.

Sounds like someone should implement a blame option for "ignore whitespace - show latest author with non-whitespace changes"!

git blame -w already does this: http://www.kernel.org/pub/software/scm/git/docs/git-blame.ht...

git blame -w

Mercurial already has this as well:

  hg annotate --help
  ...
  -w --ignore-all-space    ignore white space when comparing lines
  -b --ignore-space-change ignore changes in the amount of white space
  -B --ignore-blank-lines  ignore changes whose lines are all blank

If multiple people rearrange the white space at the same time as adding variables (e.g., because the new variables are of types whose names are different widths, both wider than the old gap), you are more likely to get a conflict than if they just leave the spacing alone. Many version control systems seem to tend to do their automated merges line by line, and this sort of edit seems to give them less to work with. [8c99a51796e06219f472f78a5c081dd664da83dc]

Then the wrath comes when you get latest (pull, update, fetch, rebase, call it what you will) and have an inconvenient merge forced on you! I've always personally found the fact that it's just adding or removing white space especially galling :) - but tastes may differ.

Totally agree and I was really surprised by this. One line patches can turn into 30 lines just to reformat the surrounding code.

I do use vertical alignment, but that's not necessarily how I'd align the above lines. Assuming y and z are related, but x is not, I'd do them like this:

    int x
    int   y
    float z

I might add a blank line between x and y, too.

If you do vertical alignment such that it emphasises semantic relations, you avoid commits that change more than they should, and it also helps draw your eye to relationships between variables.

I'll make exceptions myself if there is one declaration that is just way longer...

    int   x
    int   y
    float z
    MyReallyLongTypeHere foo;

Other than that, I tend to prefer having the variable names line up. Though doing mostly JS and C#, I can use var pretty much anywhere an assignment happens, even with null initialization.

    var foo = (sometype)null;

The bigger issue to me is comma first vs comma last... I find that comma first is easier to notice a missing/extra.

You usually aren't looking for a line based on the type... you're usually looking for a specific variable... with your variables lined up, that portion becomes faster... scanning for y in your second example without the variable declarations lined up for example. This advantage outweighs the slight hinderance of the separation on a given line. That, and many editors will highlight the line with the cursor on it. Which alleviates the issue you point out a bit.

I'm guessing that Carmack did a lot of assembly language programming and that the vertical alignment comes from that. I've done a ton of assembly programming and I find myself aligning code in C because I find it easier to scan.

It's funny you mention that, as I'm using the companion program (http://google-styleguide.googlecode.com/svn/trunk/cpplint/cp...) on the code for my current project right now. My only complaints is that much of the cpplint program checks for arbitrary style choice versus possible issues. Sure, most of the style I agree with, but I've actually hacked on that program a bit because the style guidelines are hardcoded in it. I'm halfway tempted to make it more flexible in terms of style, or at least separate the style components from the linting parts.

That's my pet peeve about many linters as well - I don't use jslint because it has many of Crockford's personal style tastes embedded in it, several of which I disagree with. In cpplint's (and perhaps jslint's) defense, it was written for one specific organization with broadly-accepted style guidelines, and open-sourced "in the hopes that it'll be useful, but without any warranty of any kind".

jshint was started in part to separate out the actual warnings from Crockford's style in jslint (it is also supposed to be more configurable with regards to style-type comments). It might be worth a look if that is the only reason you disliked jslint.

Reply on news.ycombinator.com