Skip to content

Instantly share code, notes, and snippets.

@trevnorris
Last active August 9, 2016 20:38
Show Gist options
  • Save trevnorris/c4ffc0bdae7cb81526de to your computer and use it in GitHub Desktop.
Save trevnorris/c4ffc0bdae7cb81526de to your computer and use it in GitHub Desktop.
Quick notes on why constraining cpl is an advantage when writing source
While the standard 80 character limit for source code can be traced back to the
IBM punch card[1] it can still be seen as a good upper bound for how long lines
of text should be on modern high definition displays.
First thing we must acknowledge is that source code is not read in the
traditional sense. Instead developers scan the source using non-linear eye
movements[2] or stay fixated in a small area of code while working out the
logical details of code being written. The fixation on a single location, even
for more than a few seconds, leads to a loss of visual accuity. Which occurs
when the eyes do not perform frequent saccadic eye movements.[3] Further
supporting there is no reading comprehension advantage to allowing long lines.
The following is an example how long lines may improve initial reading, but
inhibit the ability to simultaneously perform vertical and horizontal scanning
of the code:
if (check_value >= test_value && options_object.list.option1 === default_option || arguments_list.is_string != user_option && state_of_the_world_check()) {
arguments_list.is_string = false;
the_world_is_okay = false;
new_options = {
default_option,
state_of_the_world: state_of_the_world_check(),
do_more: false,
error_string: 'something went horribly wrong',
};
}
The resolution of my laptop screen allows for approximately 7 characters per
centimeter (or 18 characters per inch). This means to jump from the beginning
of the last conditional to the first character in the body the eye needs to
jump approximately 18cm or 7in. The further the eye needs to move between two
points the further those two points can be maintained in the peripheral of the
previous position. Making it more difficult to re-obtain a possibly previously
viewed code position. This doesn't include the added difficulty of vertical
scanning for the correct line of code in between all the others.
Code forms an imprint on one's memory. More than simply the name of functions
or variables, the shape of the code can help it be distinguished. As an
example, Sublime Text's code scanning sidebar makes it easier to quickly scan
for the code's form. Todays editors also allow using multiple panes for code
editing. So while we may have some 2000+ pixels for text, that doesn't mean
they won't be occupied by N panes containing that code. Constraining the number
of characters per line helps prevent word wrap and thus preserve the code's
imprint.
Today's code review software generally allow placing comments per line of code.
By breaking code into discrete segments the review process can be made simpler.
As comments on a single line are more likely to address only a single issue.
[1] https://en.wikipedia.org/wiki/Punched_card
[2] http://research.microsoft.com/en-us/um/people/abegel/papers/eyetracking-icpc2015.pdf
[3] http://learning.eng.cam.ac.uk/pub/Public/Wolpert/Publications/HarWol06.pdf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment