6 ms·
80 is an _awful_ width for code in a programming paradigm encouraging long variable names. If you're comparing two values from class.accessor, you fly right pas
by kiruwa 10y ago
80 is an _awful_ width for code in a programming paradigm encouraging long variable names. If you're comparing two values from class.accessor, you fly right past 80 characters if you have any indentation at all. Namespace hierarchies pretty much put you over the limit if you use named constants in your constructors.
If you actually use long/descriptive variable names, you can mentally process much wider text quickly, invalidating the research the "80 character optimization" was based on.
Personally I use a 145 character width, because that fits nicely on my portrait-oriented monitors, with room in both left and right margin for the editor to highlight/mark. 80 character wide limits on a modern project is like an adult riding a "Big Wheel".
- hughes 10y agoHas anyone tried enforcing a variable-reference-per-line limit? Eg. if the limit is 4, then these two lines equally hit the limit: foo = bar(baz, qux) myClassInstance.someWritableVar = lib.someFunction(param1, MyOtherClass.constants.FOO) The second line is well over 80 chars, but may be as understandable as the first.
- kiruwa 10y agoIt effectively limits all functions that return a value to 2 parameters. I rarely go over that, but it would seem a bit arbitrary to bump into.
- to3m 10y agoYou can press the Return key? :) const uint64_t *p=bsearch(&ref->u, df->file_offsets, df->num_file_offsets, sizeof df->file_offsets[0], &CompareU64s); That's from emacs. It's a bit hit or miss whether editors do something nice like the above, or just indent the arguments by one stop, but other options seem to be fairly rare. I generally have one function call per line for ease of debugging. Nothing worse than having to do a fiddly step in/step out dance when you're trying to think about what's going on. But it's also good for keeping on top of line lengths too.
- kiruwa 10y agoEh, seems fine, just seems odd to be forced to do that for a three-argument function.
- sklogic 10y ago> 80 is an _awful_ width for code in a programming paradigm encouraging long variable names Which is exactly why all such paradigms are _awful_.
- kiruwa 10y agoAll hail strpbrk()! Do you have any defense of that? I'd be interested to read it. I think every article on coding advice I've read for the last decade favors long and descriptive function/variable names.
- sklogic 10y agoDescriptive function names - yes, of course. With one function call per line. But long variable names?!? There is no place for such an abomination under this sun.
- kiruwa 10y agoIncluding class variables? Their context is far larger than the immediate code you're looking at, longer/descriptive names seem basically required there, as they have essentially similar scope to functions. (Same logic applies to making them longer) You'll note... that was my original example.
- sklogic 10y ago> Including class variables? You mean field names? A paradigm where you have such a thing is _awful_. Seriously. And this is exactly one of the reasons why it is awful and why it leads to an unreadable and unmaintainable code.
- kiruwa 10y agoAre we anti-OOP then? And no, I don't believe you. Making your variable names more descriptive does not make your code less readable. Even when it's not strictly necessary, it's not harmful to comprehension UNLESS you refuse to move from a completely outdated line width. Some people argue that it takes longer to type and edit. But as we all know, we spend far more time reading than writing code, and modern editors (like vim!) have solved this non-problem anyways.