[HN Gopher] Fundamentals of Optimal Code Style
___________________________________________________________________
Fundamentals of Optimal Code Style
Author : todsacerdoti
Score : 46 points
Date : 2021-03-24 23:51 UTC (23 hours ago)
(HTM) web link (optimal-codestyle.github.io)
(TXT) w3m dump (optimal-codestyle.github.io)
| okareaman wrote:
| Linus Torvalds disagrees about line lengths for what it's worth:
| https://news.ycombinator.com/item?id=23356607
| m33k44 wrote:
| At one point he use to be fanatic about it. The VIM
| configuration line specific to linux kernel development
| originated from that insistance on 80 chars per line in the
| early days.
| [deleted]
| rudedogg wrote:
| I find it difficult to have meaningful variable/function names
| and stay under 80 characters.
|
| Plus, with code completion (especially in a strongly typed
| language) it's no longer necessary to optimize for fewer
| keystrokes.
| smoe wrote:
| I do think having lines around 80 characters makes it more
| fluent to read code. It is not about saving keystrokes or to
| be able to do split screen even on smaller screens.
|
| But what has worked better for me is to have it as a soft not
| a hard rule. Better to have some lines go over a bit than
| having awkward breaks that make it harder to read
| RcouF1uZ4gsC wrote:
| One thing a lot of these supposedly grounded in congnitive
| science ignore is that the human brain is crazily adaptable. For
| example, just look at reading. Who would have thought that the
| human brain can process "fruit" about as quickly as seeing an
| image of a fruit, even though the glyphs of "fruit" are nothing
| like a real fruit.
|
| In the same way, I believe consistency is probably a more
| important thing than actual indentation and spacing. If it sees
| it often enough, the brain can pretty quickly adapt to about
| anything.
| Ankintol wrote:
| I'd be curious to see experiments with variable numbers of line
| breaks to create additional structure. I find my own code
| significantly more readable by separating certain "sub-blocks" of
| code with two line breaks, with their internal structures having
| single line breaks. thing_1_a thing_1_b
| thing_1_c thing_2_a thing_2_b
|
| It fits into the framework proposed here but is not mentioned
| specifically as having been investigated.
| viklove wrote:
| The problem is, to most people it just looks like you made a
| mistake. If you want to create breaks in your code, consider
| adding comments or breaking blocks out into their own
| functions.
| twic wrote:
| In some long functions (really only very long app-setup
| functions), i break up related bits into blocks:
| { thing_1_a thing_1_b
| thing_1_c } { thing_2_a
| thing_2_b }
|
| Blocks are are a language feature in a few languages, but are
| barely ever used, so it is rather weird to write and read at
| first.
| danlugo92 wrote:
| Note to onlookers: blocks can soemtimes act weird in
| javascript. I loved using them but alas.
| benreesman wrote:
| Tangential at best, but I derive great benefit personally from
| extensive use of `paredit-mode` (even in curly brace languages)
| along with brace matching and block highlighting when trying to
| figure out the structure of a piece of code.
|
| I imagine there are similar tools available for other
| environments.
| kazinator wrote:
| > _When I speak of objective readability, I mean that the full
| readability of a text consists of a subjective component, caused
| by developed habits and skills, which we talked about above, and
| an objective one._
|
| > _Thus, the subjective component is associated with some private
| habits that can be changed, and the objective - with the general
| psychophysical features of a human 's vision, which we do not
| assume is possible to change. Therefore, when talking about
| optimizing the text of a program, it makes sense to talk only
| about the objective component of readability, and therefore
| further in this article, the term readability will always refer
| to this component of it._
|
| Although this separation may be necessary to set the scope for
| the rest of the text, a lot of which is about cognitive processes
| that are "wired" into the human visual system and cannot be
| changed by learning, the above somehow not ringing true for me as
| a generality and detracts from the text.
|
| Why it isn't ringing true has less to do with the
| subjective/objective separation _per se_ and more with the author
| 's relegation of learned skills into the realm of what is
| "subjective".
|
| When people acquire skills, and that makes some tasks easier
| compared to untrained people, that difference categorically is
| not subjectivity. It is not subjectivity because we can reproduce
| the training effect in person after person, and even measure it
| with some kind of numbers that we can plot on nice graphs and see
| things like that similar "learning curves" are consistently
| reproduced in different people.
|
| When we optimize we cannot discount this "subjectivity". We must
| _assume_ it. We must assume it because the purpose of optimizing
| the activity, such as reading code, should be geared toward
| someone who will be doing it a lot. Someone doing the activity a
| lot will learn something, whether we like it or not, and that
| learning will reduce their difficulty.
|
| To use a code optimization analogy, modeling the human as static
| is like generating code based on the machine not having branch
| prediction or caching.
|
| I think the subjectivity we should discount is in how we measure
| readability. If we, say, ask subjects to rate the readability
| from 1 (very poor) to 5 (very good), _that_ is subjectivity we
| might not want.
|
| Lastly, if you're going to tell the reader you won't be
| discussing subjective aspects, then it behooves you to
| subsequently refrain from wording like _" the program text often
| looks like one poorly structured massive chunk"_ and _" placing
| the last open brace at the end of the line looks quite natural,
| and the resulting space only adds a small accent, compensating
| for the small visual mass of the last block"_.
| Ankintol wrote:
| I think the author's POV still stands just perhaps needs some
| massaging the framing.
|
| > When people acquire skills, and that makes some tasks easier
| compared to untrained people, that difference categorically is
| not subjectivity. It is not subjectivity because we can
| reproduce the training effect in person after person, and even
| measure it with some kind of numbers that we can plot on nice
| graphs and see things like that similar "learning curves" are
| consistently reproduced in different people.
|
| It sounds like you're referring to convention. Adhering to
| conventions a reader is familiar with definitely improves
| readability, but _any_ style can be improved by adherence to
| convention, so we want to ask, what is the most readable style
| before we start layering on conventions?
| datavirtue wrote:
| An aweful pedantic tome for a problem of one's own making.
| Compose and you won't have any readability problems.
|
| People write a method/function and then don't bother to pull out
| blocks of specific functionality that can be contained within
| other "helper" methods.
|
| Your 100+ line method can always be refactored to a 20 line
| method that calls the other smaller methods needed to compose its
| total functionality.
|
| Not only can I now read it, I can understand it.
|
| Giant blocks of code manufacture bugs.
| spaetzleesser wrote:
| I have worked on code bases where they followed the 20 line per
| method rule religiously. It resulted often in artificially
| broken up functions that were way harder to read than one big
| function. I would call it "small function spaghetti code".
| cloogshicer wrote:
| I respectfully disagree. If those functions are only used in
| this one place, I'd much prefer to have the code in one large
| block. John Carmack makes a good argument for why:
| https://news.ycombinator.com/item?id=25263488
| m33k44 wrote:
| The rule of thumb of 80 chars, which was(sometimes still is)
| applied for width, also applies for height: a function should
| not be more than 24 lines :) If it is greater than that then it
| needs to be refactored. Helps in readability as one does not
| have to scroll to read the entire function. Of course these
| rules came into being when terminals were 80wx24h. This was a
| guideline for Linux kernel developers for many years.
| tasty_freeze wrote:
| I think strict adherence to such rules is silly. Some 20
| lines functions are massively more complex than some 120 line
| functions.
|
| If the computation is simple and linear, then long functions
| are fine. If there are nested loops and if statements and
| other forms of flow control and deep nesting, then long
| functions are painful.
| spaetzleesser wrote:
| I have been coding for a long time and I believe more and more
| that you can put as much science in as you want. But in the end
| these things are highly subjective. Some people like it one way,
| some the other way. And in the end you can get used to almost
| anything once you have been doing it for a while.
|
| I wouldn't mind if languages left no freedom for formatting and
| enforced a style. People would get used to it and a lot of
| ultimately fruitless discussions wouldn't happen.
___________________________________________________________________
(page generated 2021-03-25 23:01 UTC)