Hacker News Reader

Comment by userbinator | Hacker News Reader

I've seen a lot of very different styles of code over the years, and I can safely say that some of the most productive programmers I've worked with have been ones with surprisingly unusual styles.

That said, using a programming contest as a judge is also likely to bring out the more unconventional styles, like minimised whitespace or indentation.

View on HN

What do you think of my coding style ?

https://gcdnb.pbrd.co/images/hgHbrzHh2mWT.png?o=1

Over the years I came to use more and more custom vertical alignment of short code lines (whatever the language is). This makes semantic similarity/symmetry stand out, elicit functional decomposition, and enables one to have a complete one-screen bird's eye view over complex problems like this MQTT pulser that trigger interrupts in unison (because musicality of what appears in my MQTT console matters too):

https://gcdnb.pbrd.co/images/kpJaZMfoWPtP.png?o=1

looking at the left is nice, you can see all the various functions very quickly. but the actual code just looks like visual noise to me, blending together, not clear where sub-blocks are within functions, "lines" (as in units separated by semicolon) blending together too.

If I was tasked with changing anything in there, or analyzing the code, the first thing I would do is run autoformat on it. even if I have to preserve the code style, I would just translate it back once I'm done

One thing I notice myself doing a lot is using lots of empty lines in my code. Sometimes I go really overboard with it, to the point that every other line is empty. I feel like it helps me read the code more easily. This seems sort of like the antithesis of that.

> One thing I notice myself doing a lot is using lots of empty lines in my code. Sometimes I go really overboard with it, to the point that every other line is empty. I feel like it helps me read the code more easily. This seems sort of like the antithesis of that.

One trick for that is making your height line higher in focused mode in the editor.

An ex co-worker had this on VSCode and looked very useful.

Imagine if lawmakers got this hung up on indentation. Not the wording, correctness, or effect. The indentation. We would say they were fiddling while Rome burns.

If you are working on your own you do you. If you are working in a team pick a style that is okay and has great tooling and support in different editors.

As this exchange proves everyone has opinions about this stuff. Standardisation is more important than optimal choice especially as everyone thinks theirv choice is optimaland yours is terrible. It doesn't have a huge impact, solve it once and make it go away so you can focus on everything else.

Just set git to format everyone's code on checkin and never talk about it in a code review again.

Yes, let's follow the lawmakers excellent example of swift coherent action.

Sure, but this thread of conversation started with someone specifically asking for opinions on their indentation. It's not like the discussion was about the code, and this is just a big side-track of the actual discussion.

I think the semi-obsession we have with "correctness" in style is actually something programmers do a lot better than most other disciplines.

Arguing over indentation is functionally the same as arguing over unix principles, or frameworks or languages. The fact that we're always looking not just for the solution, but the right solution, on every level of the process, is part of what makes programming so beautiful and enjoyable.

Law is actually a perfect example of the opposite; without that obsessive concern for correctness, the systems created are hopelessly confounding and difficult to navigate.

> Imagine if lawmakers got this hung up on indentation. Not the wording, correctness, or effect. The indentation.

I mean that seems reasonable to me. If someone submits a giant bill with no indentation/paragraphs/punctuation etc. then it should be rejected. Being able to grok the bill itself would be an important part of then determining whether or not to pass it.

> If I was tasked with changing anything in there, or analyzing the code, the first thing I would do is run autoformat on it. even if I have to preserve the code style, I would just translate it back once I'm done

This could be done with local reindentation/deindentation. You'd need some way to map back to the original style, maybe treating the whole process like a git edit, putting a newline before each new addition, highlighting it, with a checkmark button to "commit" them once the indentation is adapted to the original style, and by "commit" I mean make the highlighting go away.

However the criticism about the right part of the code being visual noise I see in your reply and others is somehow unfair, the second pic bordering on the limits of what I find acceptable myself. It's still linguistically readable as in you'd still be able to replace the parens and braces by reading that one line of code aloud. It's not code that's supposed to be readable in a typographical sense, with harmonious spacing meant to catch the wandering eye like an ad, it's code that was written to be thought through. Sit and think. For 30 minutes before hitting 'build'. After minor compilation errors and the first successful build, I had just a single one-line fix to make before having the code run correctly.

I would still find it easier to sit and think about the code if it was formatted differently. To me, this reads like a book that's just one long paragraph.

Love it. I need to figure out a way to get this automatically, because it looks super useful as high-level view - I could then switch back and forth, using clang-format to go back to company-accepted style.

Love it too. Reminds me of the terseness of Haskell, which I also enjoy.

Whenever I need that "high-level view" you mentioned, I enjoy seeing the whole module without having to scroll/search. In codebases where I gotta jump around too much, I feel disoriented and slowed-down. Like for example on Rails classes where single-use variables are replaced by single-use private methods, that are often far away from it's original usage point. I understand the rationale for doing it but it still tax me mentally when trying to get a holistic understanding of the code.

But then again, some people get used to sparse code and for then I assume such terseness can be overwhelming. Oh well. I just wish they could see my point of view too.

I really consider this a false dichotomy. It's a limitation of tooling (and ultimately of our plaintext-based mode of programming, in which we always edit the single, canonical form of the source code).

My preferred form really depends on why I'm looking at particular piece of code at a particular moment. I like my code sparse and modular if it eliminates details I don't care about. I love my code dense, tight and inlined, if it lets me fit all details I need on a single screen, or otherwise minimize the amount of scrolling and jumping between files. Depending on my particular goal, the same code can be perfectly readable, or a horrible mess.

In practice, I find most of the code I deal with too sparse, but that's again the function of the work I typically do.

Not sure what he thinks but here's what I think. Although the verticality thing isn't bad in and of itself (it does look nice) it effectively gives you less space on the screen which encourages usage of space saving measures like one letter variable names and abbreviations. This makes it difficult to understand your intention and may make it difficult for someone else to take over your project.

It's organised but unconventional. Not hard to read. Incidentally, I've found that embedded stuff,which your fragment seems to be, tends to have the most examples of such unconventional styles, often written by EEs or specialists in other fields who learned programming as a side-endeavour. Zero indentation, and code that otherwise looks like English prose, is also surprisingly common there --- and yet they seem to have little trouble reading or writing such code. Here's a memorable example of that: https://rloewelectronics.com/

I think that's standard/conventional coding style for assembler?

(Which the example source file I found was. Btw HTTPS error)

There's some C in there too. Example: https://rloewelectronics.com/distribute/PATCHMEM/VER7.2/PATC...

My code style too became more and more „vertical“ over the years — I‘ve found it to be much better scannable and therefore comprehensible especially outside its original authoring context (e.g. when doing code reviews in the web browser interface of BitBucket or GitHub).

Same here. Having my eyes jump and zigzag (https://en.wikipedia.org/wiki/Saccade) is very fatiguing.

I've been programming >40 years now.

Sorry, but not good. Too many statements on one line. By indenting the functions, you lose too much space at left of the screen. If I had to work with this code, the first thing I would do would be to completely reformat it.

However, if you are the only person maintaining this code, chacun à son goût!

Needs more \n, at the very least after each function to separate them. Although it is surprisingly compact to read at a glance, I think it would also cause problems with source control when automerging two statements that are the same line.

Source control is not a closed part of the problem. Diffs engine can be customized to tackle this problem, see `git difftool`, diff-so-fancy, there might even be something for Github's diff view. Something that is not often talked about or implemented (in comparison with linter use).

Well it's not often talked about because hardly anyone writes more than one statement per line.

I’m a huge fan of vertically aligning similar things, and right-side comments. I’ve been building an maintaining a plugin for my editor that aligns code into grids; vertically aligning everything in the line across similar lines. I also like conciseness too, though I sometimes back off when it gets too dense.

For an amazing comment by someone discussing and justifying very similar goals to yours, check out https://news.ycombinator.com/item?id=13571159

Purely my opinion, not a critique of your style at all, but I don’t love vertically aligning the open braces of functions, unless they’re one-line and similar (like readTDS & readEC), nor do I love starting code or data way off to the right just to align it with the first paren or brace. I want my code/data block to have a single indent, not a random content-dependent amount. It gets unbelievably stupid when function names are longer, it wastes half the page/screen, and it drives me nuts how clang-format does this by default (yes I know there are different profiles, but I’m stuck with the one my work peers chose to use). For me, the opening braces aren’t a semantic similarity that I want to see or emphasize, because the opening code for each function is expected to be different, and because they’re rarely on subsequent lines.

All that said, the most important thing when working with other people is to have an automatic formatter, and eliminate arguments over style! It’s nice to have a datapoint in the article that style has no correlation with quality of GCJ entries.

Please let this horrendous habit die.

Aside from the impossible to read without printing it out on ruled paper, change the length of one variable and your auto format pollutes git history with a five line change.

Most statements aligned like this aren't even related, they just happen to be colocated but then the (forced by the autoformatted standard) vertical alignment makes it look related.

Coding style (more precisely whitespace) is able to say a lot about the code without you even reading the code. This code style paints a picture that isn't there.

> It's a coding style that lies and it should be taken out back.

I’m a fan of only aligning things that are actually similar. The important part IMO is to make it easy to see differences in the middle of something that’s a pattern, not to extract similarity out of semantically different things (which is the reason I don’t love aligning the opening function braces). I’m also a fan of using the -w flag with git diff, and of avoiding hyperbole, but there is a valid and very good point in there about causing merge conflicts! ;) I don’t get to use my grid aligner all that often, because using clang-format is more important, so I don’t use it around other people very much. But all that said, I never hesitate to re-grid something if a variable changes, as long as I know it won’t cause a source control conflict.

* edit BTW I just realized the better argument which is that clang-format already has the very problem you mentioned: renaming anything can and will often cause reflow of text. Avoiding grid-alignment of text has very little bearing on whether this is going to happen to you. The only way to avoid formatting changes in your source control is to never reformat code, which isn’t something my team wants to prioritize, so we make do with selective application of clang-format. It’s sometimes useful to separate code changes from whitespace/format updates.

Golang, amusingly, is evidence that this not only won't die, but is not a problem. Auto formatting tools work. Well, even. And the idea of pollution in code history is signaling an ignorance of code repository capabilities. They have been able to show history ignoring whitespace changes for a long time.

It might be worth us outlining a workflow (and I’d be interested to hear yours). I realize that the impulse to be afraid of whitespace changes is reasonable for several reasons: one because git (for example) has defaults that show differences & conflicts on whitespace changes, and you have to change the defaults, two because git and other version control systems are usually much less great at managing cross-line whitespace changes, and three because not everyone is (or should have to be) an expert in their version control tool.

Specifically, the workflow here that allows intra-line whitespace without worry is to merge with whitespace disabled, and run the auto-formatter after merging. This means that vertically aligning things is almost innocuous, but having certain tools re-wrap text can still be problematic, at least as far as I know. If there are good ways to handle that second problem, I want that.

In general, change what you have to. And no more. If you are fixing whitespace on functions and lines scattered throughout the code, do that deliberately as a code cleanup. But don't expect that running an auto formatter on the entire code base will go over well.

Yeah completely agreed and good point; in my team’s case our guidelines are to never re-format something you didn’t touch in the commit - we request spurious whitespace changes to be reverted during code review, whether accidental or deliberate - but we also request that the block of code that is touched gets formatted. Every once in a while, like maybe once a year or less, we’ll re-run the formatter on the code base because too many things are drifting, and we’ll do it by first broadcasting the intent to the entire team, and then scheduling a good time for it, and lastly changing only formatting and nothing else, and finally if it causes any major problems, reverting and re-scheduling. Formatting the whole code base is never something I’d do lightly.

> and your auto format pollutes git history with a five line change.

Learn your tools: git provides "-w" to ignore whitespace changes. SVN provided a similar option. This isn't new.

This noise shows up in git greps. It's not as superficial as you think.

It’s true that searching for something will return the lines as they’re formatted. I’m certainly curious to hear how whitespace changes over time in git grep causes problems, what the problems are, and what the alternatives are. I can imagine reasons that might happen, but that particular example isn’t something I’ve experienced myself or heard of before, so I don’t know if I’m discounting it unfairly. Like I said in defense of your comment higher up, I see why people like you react to certain formatting tools this way, but it turns out that tools that insert and delete line breaks are far more serious when it comes to workflow implications than tools that only insert spaces or tabs to get vertical alignment, so it’s worth making that distinction right from the start.

I don’t think vertical alignment is going away, I think it will become far more common, and that our tools will catch up. My prediction is that git and other source control systems become more tolerant of formatting changes, and that developers in general will learn more workflow techniques for allowing whitespace churn.

For me, having the alignment and making the code more readable to me is more valuable than the minor inconveniences with source control that it might cause, and on top of that I’ve learned that there are ways to mitigate most of the issues. I’m not arguing that it doesn’t cause any problems, I’m only saying that it’s worth prioritizing for me, that there are things you can learn to do about it, that the tools give you options and will probably improve, and that vertical alignment in particular does far less damage that line-breaking reflows like clang-format impose… and use of clang-format is pretty widespread and standard in my experience.

Code does change over time. Refactoring happens. Variables are renamed. Comments change over time. We don’t ask people to avoid writing code or adding comments because the changes appear in git diff or grep, or even because they might cause merge conflicts… those things are considered an acceptable cost of doing business in software. I don’t see any reason to treat good formatting differently, within reason.

If I'm searching for commits that change lines with substring X I'm not interested in seeing commits that move variables four spaces to the left.

Oh, of course, that makes sense, you’re right. Does git grep actually do this, or were you thinking of git log or git blame? The git grep command by default is searching for a string in the working directory, not in the commit history. I do that using the “pickaxe” git log -S, or when I don’t have a substring I use git blame or git gui blame.

(Edit: I see that yes git grep can search history if you pipe in a git rev-list command. Is that what you do? Note the trivial workaround with git grep is to put variable whitespace in the regex you’re searching for. If you aren’t looking for a substring with spaces in them, maybe use the much simpler git log -S command?)

Good news: the pickaxe command ignores whitespace changes by default, it only shows you when the substring itself was changed. And git blame takes a -w flag so you can ignore these whitespace changes. -M can help too. First Google result for “git blame ignore whitespace”: https://coderwall.com/p/x8xbnq/git-don-t-blame-people-for-ch...

Git gui has a menu option to ignore whitespace changes too, if you’re spelunking through changes on a given line an don’t have an exact substring change you’re looking for.

So hypothetically, if you had version control tools that truly and completely took care of not showing you whitespace changes, and you were free to reformat your code any way you like without causing any trouble at all, if you had complete freedom, what would you want out of your text formatting tools?

Probably thinking about git log -S.

> what would you want out of your text formatting tools?

Consistent white space rules when reading from left to right.

Hey that’s good; git log -S doesn’t show you whitespace changes.

I’m not sure I follow, what does consistent mean to you, can you elaborate? Is that consistency something you have a hard time getting right now because of source control issues? I guess I was wondering about whether you had a wish list for formatting, things that you don’t have but would take if you knew it wouldn’t cause any issues with source control. Do you use clang-format, or any other auto-formatters on your team?

Reminds me of https://github.com/darius/ichbins/blob/master/ichbins.scm#L2... but written for a wider window, which helps in this style.

I have to confess I'm a lisper

Exactly. There’s a running joke when talking about code style of “Rich Hickey’s Java” - as the exemplar of weird style. (Which it is if you ever glance at core Clojure’s code base.) But RH in my mind is the epitome of one who understands real practitioner productivity.

The best code style = the one written by someone who doesn't crash prod, segfault, or mess up the hot path (allocate).

I started programming something in Python for the first time ever, a few weeks ago. (In the PyCharm IDE.)

I was somewhat afraid of the enforced indentation and newline policy, but I must say I love it, at least so far. Consistent and unified code style reduces my cognitive workload and lets me concentrate on the business logic of the classes I am working on.

When everyone has their own style, as was the case in all my previous projects (C++, C, Java, PHP), the extra friction costs some non-trivial amount of energy and time of everyone involved.

Of course there is more than just formatting to a "programming style", but still.

IOCCC is one program contest that favors surprisingly unusual styles, and some of the winners are very productive programmers. Probably not so much for what they did in IOCCC, but for the fact that they care about the source code as much as the compiled binary.

Reply on news.ycombinator.com