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
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.)
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.
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.
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.
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?
I'm not the parent, but as someone who also doesn't prefer aligning variable initialisers I can say the reason is that declaring variables and initialising them is not something I see as being tabular --- they're just a sequence of statements, and I wouldn't align them just like I wouldn't do this with a series of function calls:
foo (5, 7);
barbar (j);
do_stuff(6, 1, 7);
or this with flow control statements:
if (x == y) {
...
}
for (...) {
...
}
while(...) {
...
}
Things like array initialisers, however, I do align.
> Actually, if you were really reading "the way a computer parses it", you'd ignore whitespace completely.
I write a lot of coffeescript ;-)
Joking aside, on my current project we elide the parentheses when making function calls with arguments. So:
myfunc(foo)
myfunc (foo) ->
is an important difference when I'm reading the code. If you write:
myfunc (foo) ->
it means the same thing, but it completely throws me for a loop because I have to look ahead too far. So you are right, I don't look at it the way the interpreter does. I'm inferior and can only handle a grammar with a single look ahead ;-)
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.:
That's actual tabular data though. The variables `n` and `acc` are not the same type of thing; they don't belong in the same table. (Unless you were making a table called "local variables", but that is already obvious or redundant.)
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.
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.
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.
> 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.
It depends on context. For example, here is a function from a project I'm working on:
parseModifier : String -> Outcome Modifier
parseModifier s = case s of
"shift" -> Ok Shift
"ctrl" -> Ok Ctrl
"alt" -> Ok Alt
"meta" -> Ok Meta
"command" -> Ok Meta
"windows" -> Ok Meta
x -> Err <| "Unknown modifier: " ++ x
I find it easier to read as is rather than if I dropped the alignment:
parseModifier : String -> Outcome Modifier
parseModifier s = case s of
"shift" -> Ok Shift
"ctrl" -> Ok Ctrl
"alt" -> Ok Alt
"meta" -> Ok Meta
"command" -> Ok Meta
"windows" -> Ok Meta
x -> Err <| "Unknown modifier: " ++ x
As developers we spend more time reading code than editing it. Optimizing for readability seems like a better goal than optimizing for edit speed. Besides, most editors have functionality to align code. When I am looking over a file, the second example looks like a jumble of words to me, while the aligned version seems easier to parse (ha).
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.
O'RLY? Does your style guide suggest lining up comments? Why? Does your email app separate things into columns? Do you think it would be more readable if it didn't? How about your bank statement, spreadsheets?
And in fact if there are great differences in the length of the names it makes it harder to read as scanning across and maintaining the correct line becomes more difficult.
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).
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.
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)
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.
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.
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.
There is nothing about niche audiences that make them particularly forgiving consumers. Quite the opposite, actually. Niche audiences tend to be the most critical. Don't readily hand them ammunition to dismiss a project early.
A niche audience might look past silly logos, or even adopt them wholehearted as part of their "other" identity. But they are still consumers and still need to be marketed to. In this case, a bad logo is better than no logo.
But bad copy is just bad copy.
Most people won't actually use any particular project they read about. Most of early-stage marketing (and posting links like this to link-share sites like HN) is about gaining mind-share. You're investing time now in getting your name out so that--6 months from now--people who will eventually become your core users will say to themselves, "yeah, I remember hearing about that."
And when they say that to themselves, they are going to retain that mental picture of the project from when they first heard about it. If that picture is "incomplete, pie-in-the-sky", then they will continue to think of it as that. You now have to fight against the long-tail of converting people over to the new normal of your project being "complete".
Granted, if Jonas Termansen has no interest in having users, then he should just ignore my post completely. But then, why did he prop up a website for his project, a project he's labored on for 4 years now?
If you put that kind of effort into something, you owe it to yourself to not sell it short.
The word 'liberal' in a European context ranges in meaning, and often encompasses many aspects of what those in the US would recognize as 'libertarian'. It just really depends on the context though. Depending on the country, 'liberalism' may be associated with center-left, center-right, or both (see UK LibDems as an example). In general, though, it is typically used in contrast to both right wing conservative parties and left wing social-democratic parties.
This is indeed an annoying problem. Please either decrease the font size or use 2 or 4 space indentation (without mixing tabs and spaces) or just steal some space from the sides.
