6 ms·

I agree with everything except abbreviations, but to be honest, I think my worst habit it just trying to use words with the same number of characters for differ

I agree with everything except abbreviations, but to be honest, I think my worst habit it just trying to use words with the same number of characters for different variables so they align well with monospace font. e.g. int num = 42; int acc = 0; instead of; int n = 42; int acc = 0; and it gets worse when things get complicated; vector<int> dist; // stands for distances vector<int> excs; // stands for excesses Does anyone else have this problem?

ttty 11y ago
int n = 42; int acc = 0; Fixed Edit: Install http://wbond.net/sublime_packages/alignment http://wbond.net/sublime_packages/alignment and add this key binding `{ "keys": ["ctrl+shift+a"], "command": "alignment" }`.
- scrollaway 11y ago
  Which, when you add a third variable "stuff", will require you to go back and add a space for both n and acc, pollutting both the diffs themselves (making reviews harder) and the git-blame (making pinpointing bugs harder).
  - ttty 11y ago
    There is a plugin in sublime text that I just select the lines and hit ctrl+shift+a and alignes everything in one hit.
    - scrollaway 11y ago
      The way you realign your variables is inconsequential to the pain it causes your teammates (and potentially yourself) come time to look at the diff. And yes, I know about git diff -w, but 1. not all tools built around git support it and 2. not everybody uses git.
    - jacquesm 11y ago
      That there is a plug-in that makes it easy does not make it right. If you're working just by yourself you can do whatever you want but teamwork takes a slightly different attitude when it comes to reformatting. It's all too easy to get into a whitespace war with someone else (and you'll both look so productive!). A good team member will change what is needed and will separate cosmetic changes and functional changes by placing them in different commits and will apply the style guide while doing so. Tracking bugs through changesets is hard enough, no need to make it harder on purpose.
  - mappu 11y ago
    git diff -w
    - Macha 11y ago
      Is there a git blame -w?
      - scrollaway 11y ago
        Yes.
    - jacquesm 11y ago
      Yes, git diff -w is possible but it is not (unfortunately) the default (though I can see good reasons why it isn't). Also, note that you can do the same in github: Append ?w=1 to the url for the diff viewer and you'll get the whitespace ignored version.
- jacquesm 11y ago
  That's actually right against the style guideline of many projects which tell you explicitly not to do this but to simply put the = sign and value right after the variable name and be done with it. Lining them up serves no purpose and does not in fact make the code easier to read.
  - ttty 11y ago
    To be honest it actually makes code cleaner and therefore easier to read. It's like design have you heard about grid? this is the same thing. Your eyes have to flow the lines. If not everything seems a mess.
    - jacquesm 11y ago
      Ask your revision control system what it thinks about that and your teammates when you submit a 500 line diff for review when a 10 liner would suffice. That's only marginally better than someone checking in a diff when their editor converted tabs to spaces or vv. Whitespace edits are the code equivalence of wikipedia formatting changes to increase the number of articles you've worked on without actually contributing anything. Also, if you think that is easier to read you are actually setting yourself up by being deceived by formatting because you'll be skipping bits based on assuming you know what they say. Those are hard lessons to learn but the best way to understand a new piece of code that you're reading is not to read it like a book but like a machine, with a pencil and a notepad tracing the values of the variables as you execute the code in your head (or on the paper if it gets complex). You don't need to run the whole program that way, just the sections that you feel are hard to understand.
    - mc808 11y ago
      I vote for harder to read (and write), except when the variables are so tightly coupled that they should probably be in an array or other structure anyway. But ideally this is something that should be decided by each developer's personal editor config, like tab widths for indentation.
    - SamReidHughes 11y ago
      > To be honest it actually makes code cleaner and therefore easier to read. It does not logically follow from the code being "cleaner" that it is easier to read. Having to scan across a field of whitespace to get to the number makes it harder to read and easier to make mistakes. Having the indentation of the number be unrelated to the length of the variable name adds another aspect that makes it harder to read and easier to make mistakes. It's also harder to edit, which makes you do fewer edits that make the code materially better.
- mikekchar 11y ago
  You will find, if you spend the effort to look, that different people process information completely differently. To someone who views this as a table, the above is so much more readable that it doesn't even bear thinking about. To someone who reads code the way a computer parses it (as I do), the added space can completely throw them for a loop. What the hell are you doing with n? Oh, if I look far enough, there is an assignment there. Very likely you will see what I've written and find it incomprehensible because you have never looked at an expression the way I do. What's worse is that there isn't just 2 ways to look at it. Coding style purists usually don't realize that they are simply fooling themselves into thinking that their way of looking at something is optimal for everyone. As someone else mentioned, the day when we can express how we want our code formatted and our editors will instantly format it that way (for everyone) can't come soon enough. But until then, it would be best to simply realize that there is no "best" way and that you should go with what the majority of the team likes, no matter what you personal preference is.
  - greggman 11y ago
    I'm curious, would you prefer your favorite music player list things like this Madonna, Rain, 3:45 Lady Gaga, Bad Romance, 4:17 U2, In God's Country, 3:57 LCD Soundsystem, I Can Change, 6:31 vs Madonna Rain 3:45 Lady Gaga Bad Romance 4:17 U2 In God's Country 3:57 LCD Soundsystem I Can Change 6:31 I'm not questioning that you find columnized code hard to read I'm just wondering would that apply to all forms of info? Your email list with time, name, subject. Your bank statement with data, biller, amount? If not any idea why tables work for you sometimes and not others?
    - barrkel 11y ago
      Tables require sequences of structurally isomorphic operations. Columnized code can work very well for matrix calculations, for example. But most code that has structural isomorphism should be replaced by a loop or a function composition; repeated structural isomorphism is a redundancy that can be eliminated. Aligning the initialization of a bunch of unrelated variables is a bit of a mixed case. Sequences of initialization are much more common in older languages, like C, that don't permit delaying the declaration. I don't have a strong opinion either way. If the data being initialized is structural, a tabular format should definitely be used, if it isn't fighting the tool (some IDEs etc. autoformat, or lint complains on unnecessary whitespace). If data is not structural and the variables aren't strongly related to one another, I don't see a good argument in favour of alignment, particularly when variable names can have wildly different lengths, e.g.: source = 10; timeout = 20; wait_count = 30; ch = 0; accumulator = 40; access_denied_retry_callback_list = []; I find this substantially harder to read (see name to value and vice versa) than non-tabulated initialization. source = 10; timeout = 20; wait_count = 30; ch = 0; accumulator = 40; access_denied_retry_callback_list = [];
- a3n 11y ago
  I think both practices are pathological. The GP is restricting all variable names to an arbitrary length that will likely obscure meaning. The parent is arbitrarily determining line length based on whichever variable is longer; he may also be mixing in the GP's arbitrary var length rule in order to get a visually pleasing line in the local context. Prose is obviously different, but it's probably worth considering that the only consideration for the length of a paragraph is the rules of paragraph writing, and not at all the physical length of words and sentences. And then there's refactoring and renaming, and what that does to your artfully placed characters. Figure out your placement and spacing rules (or better, use a canned set of rules), use them, and think about other things.
  - yellowapple 11y ago
    The point is less about aesthetics for their own sake and more about readability; the LHS and RHS end up being readable as if they were columns, which leaves less work for the brains of coworkers or future selves to perform when trying to mentally parse it.
- Gibbon1 11y ago
  In the past I've wanted a tool like that, but now I've come around to the idea that I want an editor that will display the code the way I'm used to however it's formatted. Lining up the equals signs would be a good candidate for an display formatting plugin. One the other hand when I've raised that idea with programmer friends of mine you can see the hair stand up on the back of their necks. People seem to really hate the idea that the editor might show you seaMonkey(do) instead of sea_monkey(do)
SamReidHughes 11y ago
I try to pick words with different lengths. They're more visually distinguishable.
- jacquesm 11y ago
  And try to pick words that are lexicographically distant from each other to minimize the chance of single letter typos changing the meaning of the code.
  - JadeNB 11y ago
    Of course it's a tiny matter of terminology, but you probably mean Hamming distant, not lexicographically distant. `zaaaaa` is lexicographically farther from `aaaaaa` than is `bbbbbb`, but Hamming closer.
rwallace 11y ago
I solve that problem by programming in a proportional font, which removes the temptation. (I know some people program in a monospaced font for various reasons, but in my opinion, anything that needs a monospaced font is a bad idea in the long run anyway.)
tmuir 11y ago
The way I think of abbreviations is this: if you would use the abbreviation when describing the code in plain English to another developer, then they are fine. Otherwise, don't abbreviate. Trying to make everything the same number of letters has very little utility, especially if you are giving up readability. Your also bound to run into naming collisions. Is rec record or receive? Is acc accumulate or accessor? Even if you can't touch type, there are a ton of editor with autocompletion. The whole point of coding style is that someone else will have to read and maintain your code. If you step away from your code for even a month, it's almost like reading someone else's code when you come back to it. If you're writing code that will never be seen again, and simply has to work once, you don't need any style whatsoever. But that's not very common. I think the biggest motivator is having to debug/port someone else's code full of magic numbers, short variables, long functions, global variables, and no comments.
joesb 11y ago
I try to use full word, except for loop variable. Not every shorten the same word the same way, not even yourself next year.
peter_hilton 11y ago
> my worst habit it just trying to use words with the same number of characters for different variables so they align Yes, you have worse problems than ambiguous abbreviations :) That doesn't make the abbreviations okay, though.

ttty 11y ago

int n = 42; int acc = 0; Fixed Edit: Install http://wbond.net/sublime_packages/alignment http://wbond.net/sublime_packages/alignment and add this key binding `{ "keys": ["ctrl+shift+a"], "command": "alignment" }`.

scrollaway 11y ago
Which, when you add a third variable "stuff", will require you to go back and add a space for both n and acc, pollutting both the diffs themselves (making reviews harder) and the git-blame (making pinpointing bugs harder).
- ttty 11y ago
  There is a plugin in sublime text that I just select the lines and hit ctrl+shift+a and alignes everything in one hit.
  - scrollaway 11y ago
    The way you realign your variables is inconsequential to the pain it causes your teammates (and potentially yourself) come time to look at the diff. And yes, I know about git diff -w, but 1. not all tools built around git support it and 2. not everybody uses git.
  - jacquesm 11y ago
    That there is a plug-in that makes it easy does not make it right. If you're working just by yourself you can do whatever you want but teamwork takes a slightly different attitude when it comes to reformatting. It's all too easy to get into a whitespace war with someone else (and you'll both look so productive!). A good team member will change what is needed and will separate cosmetic changes and functional changes by placing them in different commits and will apply the style guide while doing so. Tracking bugs through changesets is hard enough, no need to make it harder on purpose.
- mappu 11y ago
  git diff -w
  - Macha 11y ago
    Is there a git blame -w?
    - scrollaway 11y ago
      Yes.
  - jacquesm 11y ago
    Yes, git diff -w is possible but it is not (unfortunately) the default (though I can see good reasons why it isn't). Also, note that you can do the same in github: Append ?w=1 to the url for the diff viewer and you'll get the whitespace ignored version.
jacquesm 11y ago
That's actually right against the style guideline of many projects which tell you explicitly not to do this but to simply put the = sign and value right after the variable name and be done with it. Lining them up serves no purpose and does not in fact make the code easier to read.
- ttty 11y ago
  To be honest it actually makes code cleaner and therefore easier to read. It's like design have you heard about grid? this is the same thing. Your eyes have to flow the lines. If not everything seems a mess.
  - jacquesm 11y ago
    Ask your revision control system what it thinks about that and your teammates when you submit a 500 line diff for review when a 10 liner would suffice. That's only marginally better than someone checking in a diff when their editor converted tabs to spaces or vv. Whitespace edits are the code equivalence of wikipedia formatting changes to increase the number of articles you've worked on without actually contributing anything. Also, if you think that is easier to read you are actually setting yourself up by being deceived by formatting because you'll be skipping bits based on assuming you know what they say. Those are hard lessons to learn but the best way to understand a new piece of code that you're reading is not to read it like a book but like a machine, with a pencil and a notepad tracing the values of the variables as you execute the code in your head (or on the paper if it gets complex). You don't need to run the whole program that way, just the sections that you feel are hard to understand.
  - mc808 11y ago
    I vote for harder to read (and write), except when the variables are so tightly coupled that they should probably be in an array or other structure anyway. But ideally this is something that should be decided by each developer's personal editor config, like tab widths for indentation.
  - SamReidHughes 11y ago
    > To be honest it actually makes code cleaner and therefore easier to read. It does not logically follow from the code being "cleaner" that it is easier to read. Having to scan across a field of whitespace to get to the number makes it harder to read and easier to make mistakes. Having the indentation of the number be unrelated to the length of the variable name adds another aspect that makes it harder to read and easier to make mistakes. It's also harder to edit, which makes you do fewer edits that make the code materially better.
mikekchar 11y ago
You will find, if you spend the effort to look, that different people process information completely differently. To someone who views this as a table, the above is so much more readable that it doesn't even bear thinking about. To someone who reads code the way a computer parses it (as I do), the added space can completely throw them for a loop. What the hell are you doing with n? Oh, if I look far enough, there is an assignment there. Very likely you will see what I've written and find it incomprehensible because you have never looked at an expression the way I do. What's worse is that there isn't just 2 ways to look at it. Coding style purists usually don't realize that they are simply fooling themselves into thinking that their way of looking at something is optimal for everyone. As someone else mentioned, the day when we can express how we want our code formatted and our editors will instantly format it that way (for everyone) can't come soon enough. But until then, it would be best to simply realize that there is no "best" way and that you should go with what the majority of the team likes, no matter what you personal preference is.
- greggman 11y ago
  I'm curious, would you prefer your favorite music player list things like this Madonna, Rain, 3:45 Lady Gaga, Bad Romance, 4:17 U2, In God's Country, 3:57 LCD Soundsystem, I Can Change, 6:31 vs Madonna Rain 3:45 Lady Gaga Bad Romance 4:17 U2 In God's Country 3:57 LCD Soundsystem I Can Change 6:31 I'm not questioning that you find columnized code hard to read I'm just wondering would that apply to all forms of info? Your email list with time, name, subject. Your bank statement with data, biller, amount? If not any idea why tables work for you sometimes and not others?
  - barrkel 11y ago
    Tables require sequences of structurally isomorphic operations. Columnized code can work very well for matrix calculations, for example. But most code that has structural isomorphism should be replaced by a loop or a function composition; repeated structural isomorphism is a redundancy that can be eliminated. Aligning the initialization of a bunch of unrelated variables is a bit of a mixed case. Sequences of initialization are much more common in older languages, like C, that don't permit delaying the declaration. I don't have a strong opinion either way. If the data being initialized is structural, a tabular format should definitely be used, if it isn't fighting the tool (some IDEs etc. autoformat, or lint complains on unnecessary whitespace). If data is not structural and the variables aren't strongly related to one another, I don't see a good argument in favour of alignment, particularly when variable names can have wildly different lengths, e.g.: source = 10; timeout = 20; wait_count = 30; ch = 0; accumulator = 40; access_denied_retry_callback_list = []; I find this substantially harder to read (see name to value and vice versa) than non-tabulated initialization. source = 10; timeout = 20; wait_count = 30; ch = 0; accumulator = 40; access_denied_retry_callback_list = [];
a3n 11y ago
I think both practices are pathological. The GP is restricting all variable names to an arbitrary length that will likely obscure meaning. The parent is arbitrarily determining line length based on whichever variable is longer; he may also be mixing in the GP's arbitrary var length rule in order to get a visually pleasing line in the local context. Prose is obviously different, but it's probably worth considering that the only consideration for the length of a paragraph is the rules of paragraph writing, and not at all the physical length of words and sentences. And then there's refactoring and renaming, and what that does to your artfully placed characters. Figure out your placement and spacing rules (or better, use a canned set of rules), use them, and think about other things.
- yellowapple 11y ago
  The point is less about aesthetics for their own sake and more about readability; the LHS and RHS end up being readable as if they were columns, which leaves less work for the brains of coworkers or future selves to perform when trying to mentally parse it.
Gibbon1 11y ago
In the past I've wanted a tool like that, but now I've come around to the idea that I want an editor that will display the code the way I'm used to however it's formatted. Lining up the equals signs would be a good candidate for an display formatting plugin. One the other hand when I've raised that idea with programmer friends of mine you can see the hair stand up on the back of their necks. People seem to really hate the idea that the editor might show you seaMonkey(do) instead of sea_monkey(do)

SamReidHughes 11y ago

I try to pick words with different lengths. They're more visually distinguishable.

jacquesm 11y ago
And try to pick words that are lexicographically distant from each other to minimize the chance of single letter typos changing the meaning of the code.
- JadeNB 11y ago
  Of course it's a tiny matter of terminology, but you probably mean Hamming distant, not lexicographically distant. `zaaaaa` is lexicographically farther from `aaaaaa` than is `bbbbbb`, but Hamming closer.

rwallace 11y ago

I solve that problem by programming in a proportional font, which removes the temptation. (I know some people program in a monospaced font for various reasons, but in my opinion, anything that needs a monospaced font is a bad idea in the long run anyway.)

tmuir 11y ago

The way I think of abbreviations is this: if you would use the abbreviation when describing the code in plain English to another developer, then they are fine. Otherwise, don't abbreviate. Trying to make everything the same number of letters has very little utility, especially if you are giving up readability. Your also bound to run into naming collisions. Is rec record or receive? Is acc accumulate or accessor? Even if you can't touch type, there are a ton of editor with autocompletion. The whole point of coding style is that someone else will have to read and maintain your code. If you step away from your code for even a month, it's almost like reading someone else's code when you come back to it. If you're writing code that will never be seen again, and simply has to work once, you don't need any style whatsoever. But that's not very common. I think the biggest motivator is having to debug/port someone else's code full of magic numbers, short variables, long functions, global variables, and no comments.

joesb 11y ago

I try to use full word, except for loop variable. Not every shorten the same word the same way, not even yourself next year.

peter_hilton 11y ago

> my worst habit it just trying to use words with the same number of characters for different variables so they align Yes, you have worse problems than ambiguous abbreviations :) That doesn't make the abbreviations okay, though.