I wish we could talk about style in objective terms, not just opinion. Opinions are kinda stupid. Here's my opinion: https://news.ycombinator.com/item?id=26790701 (actually that's just a faux opinion to make a point, but you get the point)
And if there are no objective facts, then maybe we could just stop calling other peoples' preferred style nasty and "bad habits" as if it were objective.
More difficult to read, more difficult to edit, but the worst thing is how difficult it makes diffing code. You should try using some kind of code versioning, git is a popular choice.
Subjective, and I do not find it more difficult to read. On the contrary, I often find shorter and denser expressions (especially around obligatory fluff that doesn't actually do much) to improve readability and make it easier to focus on the interesting part.
> more difficult to edit
Subjective, and I do not find it more difficult to edit.
In general, as long as you're not using a magnetized needle as your editor, creating new declarations or moving declarators around shouldn't be a challenge. It is trivial.
Nevertheless, if we want to consider the relative difficulty of various trivial edits, it can go both ways as far as multiple declarators per line are concerned. It can be easier to edit when you have a set of related variables and you need to change the type once. If you split them on a bunch of lines, you need to remember to change every line, which is more work and larger diffs. Oh the horror...
> but the worst thing is how difficult it makes diffing code.
I agree that it can make diffs a little harder to read but I have not found that to be a big issue in practice (having worked on both styles of code professionally and as a hobby for more than two decades).
If diffs were such a major concern, then we probably should adopt an assembly-style syntax with one instruction per line and no nested indentation. That would keep lines inherently short, so you don't have to locate and read the small change on a longer line. And you'd never have to pick small changes from a large hunk that is large mainly due to changed indentation. (At this point, I'd like to make a point about how splitting everything to more and more lines isn't always good for readability but I think I made that point already.)
By the way, you might wanna try out one of these modern diff tools that can hilight the actual change on a diff line.
> You should try using some kind of code versioning, git is a popular choice.
I can assure you that "multiple variables per declaration" have never been a problem for me with git. Coincidentally, the source code of git itself does have multiple declarations per line so looks like it wasn't a big problem for the authors of git either. (Obligatory example: https://github.com/git/git/blob/89b43f80a514aee58b662ad606e6...)
I shouldn't be surprised, of course you're also the kind of person who writes terribly long lines of code. We have ultra-wide screens nowadays, better put them to good use.
Anyways, you might think you're making a point by repeating "it's all opinions", but that doesn't mean your single opinion is equal to everyone else. And on the subject of one vs multiple declarations, you're overwhelmingly in the minority.
For personal project my hard limit is 80 cols. For work stuff, mandated by employer, we do something like 120 cols with clang-format. Four or five columns of code side by side, so I can see hundreds of lines of code at once. I still prefer not to waste too much vertical space on fluff.
It doesn't sound like you understand the difference between block structured code with a function call syntax and assembly. Thanks for the attempted ad hominem btw ;-)
> Anyways, you might think you're making a point by repeating "it's all opinions anyways", but that doesn't mean your single opinion is equal to everyone else.
You keep missing the point. Did I say "that's just nasty and bad habits" about your preferred style? Nope!
All I'm saying is that it'd be nice if people stopped presenting their preference as objectively good style and telling that everything else is nasty and wrong. We don't need to share the same preferred color either.
The first comment in this thread would've been a lot more palatable if it just said "I don't like this style." That would also give the comment the right weight: it is just an opinion after all.
I don't think popularity of opinion should matter for discourse. Of course I know I'm in the minority, and that's why I think it's all that much more important to state my opinion. Or do you want to live in an echo chamber where only the popular opinion gets said and everything else is painted nasty and wrong and downvoted to hell? Well, that is pretty much what HN is today. I hope you're not contributing to that.
> you might think you're making a point by repeating "it's all opinions", but that doesn't mean your single opinion is equal to everyone else.
You're very wrong.
Readability is currently impossible to measure precisely. All the opinions are grounded in impossible to quantify and define personal skills, predispositions, and habits.
"It" may be "more readable" to you. And your friends. That is still just your (and your friends') opinion, describing a feeling you have. It's not measurable. It's not provable. It's just what you think is happening, but that's it - just a thought.
No facts. No measures. No definitions. As long as your opinion has these qualities, yes, it's equal to everyone else's.
The problem with that is that it's narrow-minded. You should try to understand that, in different circumstances and for different people, the feeling of what's readable and not readable can be drastically different from your own.
There are people who swear by ⍝P⌊ or K and say they're the most readable languages ever. Others will-tell-you-there's-nothing-wrong-with-kebab-case and that (parens (are (not (a) problem) either))))))). Some will tell you that any language will do, as long as you drown it in text (like Knuth's literate programming). Yet others will try to make prose be executable, like in Inform. Some will tell you $igil$ improve readability, some will say they don't. Some will be horrifiedSeeingCamelCase, others will_see_underscores_as_ugly. Some will fight for apps hungarian, some will lead a crusade against hungarian notation as a whole.
The opinions are varied, exactly because there is no hard data to support any single position. Your opinion is yours to have, and you may live in a time and place where people you interact with share the same opinion, giving you an illusion of importance. One step outside of your bubble will show you otherwise - it's just an opinion, one of many, and not magically better just because it's yours.
You can call me narrow-minded all you want, I'm not going to argue with someone who has this[0] as argument.
Otherwise I'll be happy to discuss about whether multiple assignments is readable or not, but when the majority of people think it's not, maybe the onus is on you to at least advance some arguments?
> whether multiple assignments is readable or not,
That's the whole point: multiple assignments (and everything else) are NEITHER readable NOR unreadable, objectively.
There is no way to argue either way. Appeal to majority is a fallacy, so it's a non starter. Other than that, there's no data, no hard facts, no measures, nothing to talk about!
Again: multiple assignements (and everything else) may feel easier to read to you. It's just a feeling. There are bound to be people who feel differently. Both positions are equally subjective.
It's further complicated by the fact that readability is NOT a simple function of lexical structure. The exact same line of code can be unreadable to you at one point, then once you learn the intent or rule behind it, it magically becomes redable. It just "clicks" and suddenly you have no problems with reading it.
There are some properties which seem to correlate with readability, like predictability. There are some hard constraints due to how the eye is built. Even if you narrow those as much as possible, the space of possible syntaxes and styles which fit in these is absulutely HUGE.
I mentioned APL. This is an example taken from the front page of APL wiki:
And this is the commentary below it: "many functions can be expressed in fewer characters than even the shortest fitting name. For example ≠⊆⊢ is but three characters, while you would need five for the name Split"
They argue that "≠⊆⊢" is more readable than "Split". And, to them, it IS - once they learned the language. This suggests that readability is much more dependent on your knowledge, skills, and habits, than on the objective shape of piece of code.
I went out of my way to learn the widest possible variety of programming languages. The spectrum of things considered readable or not is so wide that it's really hard to find ANY points common to all of the languages. If there even are any!
So, again, step outside of your bubble and your mind will be blown.
I have worked on projects where linters enforce that style, and I hate it.
You can read their justification: a programmer or code reviewer might mistakenly believe that the two variables src and c are declared as char *.
"A programmer might not know the syntax" is as stupid a justification for enforcing these rules as "a reader might not be able to read long sentences correctly" is for enforcing a stupid rule over text written in a natural language. I'm sorry that you failed to see the analogy.
They also just drop a statement like "declaring no more than one variable per declaration can make code easier to read and eliminate confusion." I can drop my opinion too: "declaring more than one variable per declaration can make code easier to read and eliminate confusion." It can also make the code shorter and easier to scan & edit.
And I think analogies involving natural language are more relevant than you think.
I would rather read "U, V, and W are phases" than "U is a phase. V is a phase. W is a phase." It's the same goddamn thing, we're declaring things (and optionally initializing them).
