9 ms·

What do you think of my coding style ? https://gcdnb.pbrd.co/images/hgHbrzHh2mWT.png?o=1 https://gcdnb.pbrd.co/images/hgHbrzHh2mWT.png?o=1 Over the years I ca

What do you think of my coding style ? https://gcdnb.pbrd.co/images/hgHbrzHh2mWT.png?o=1 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 https://gcdnb.pbrd.co/images/kpJaZMfoWPtP.png?o=1

TeMPOraL 4y ago
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.
- whstl 4y ago
  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.
  - TeMPOraL 4y ago
    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.
asddubs 4y ago
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.
- tough 4y ago
  > 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.
- shubb 4y ago
  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.
  - peteradio 4y ago
    Yes, let's follow the lawmakers excellent example of swift coherent action.
  - 4y ago
timwaagh 4y ago
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.
userbinator 4y ago
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/ https://rloewelectronics.com/
- cutemonster 4y ago
  I think that's standard/conventional coding style for assembler? (Which the example source file I found was. Btw HTTPS error)
  - userbinator 4y ago
    There's some C in there too. Example: https://rloewelectronics.com/distribute/PATCHMEM/VER7.2/PATCHM.C https://rloewelectronics.com/distribute/PATCHMEM/VER7.2/PATC...
ManuelKiessling 4y ago
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).
- altgeek 4y ago
  Same here. Having my eyes jump and zigzag (https://en.wikipedia.org/wiki/Saccade https://en.wikipedia.org/wiki/Saccade) is very fatiguing. I've been programming >40 years now.
GnarfGnarf 4y ago
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!
moffkalast 4y ago
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.
- blatant303 4y ago
  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).
  - moffkalast 4y ago
    Well it's not often talked about because hardly anyone writes more than one statement per line.
dahart 4y ago
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 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.
- onlypositive 4y ago
  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.
  - dahart 4y ago
    > 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.
abecedarius 4y ago
Reminds me of https://github.com/darius/ichbins/blob/master/ichbins.scm#L282-L367 https://github.com/darius/ichbins/blob/master/ichbins.scm#L2... but written for a wider window, which helps in this style.
- blatant303 4y ago
  I have to confess I'm a lisper

TeMPOraL 4y ago

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.

whstl 4y ago
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.
- TeMPOraL 4y ago
  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.

asddubs 4y ago

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.

tough 4y ago
> 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.
shubb 4y ago
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.
- peteradio 4y ago
  Yes, let's follow the lawmakers excellent example of swift coherent action.
- 4y ago

timwaagh 4y ago

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.

userbinator 4y ago

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/ https://rloewelectronics.com/

cutemonster 4y ago
I think that's standard/conventional coding style for assembler? (Which the example source file I found was. Btw HTTPS error)
- userbinator 4y ago
  There's some C in there too. Example: https://rloewelectronics.com/distribute/PATCHMEM/VER7.2/PATCHM.C https://rloewelectronics.com/distribute/PATCHMEM/VER7.2/PATC...

ManuelKiessling 4y ago

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).

altgeek 4y ago
Same here. Having my eyes jump and zigzag (https://en.wikipedia.org/wiki/Saccade https://en.wikipedia.org/wiki/Saccade) is very fatiguing. I've been programming >40 years now.

GnarfGnarf 4y ago

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!

moffkalast 4y ago

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.

blatant303 4y ago
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).
- moffkalast 4y ago
  Well it's not often talked about because hardly anyone writes more than one statement per line.

dahart 4y ago

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 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.

onlypositive 4y ago
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.
- dahart 4y ago
  > 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.

abecedarius 4y ago

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

blatant303 4y ago
I have to confess I'm a lisper