Artificial limits to the line length is a mistake, it's a totally arbitrary value, and has horrendous knock on effects. People end up choosing bad variable names as otherwise the lines get too long. The intention was to produce readable code that can be viewed and understood, and if that is the intention, then line length should defer to readability, not the other way around.
I had them when I used PygmyForth: F+ F- F* F/ FSIN FCOS FTAN...
Theoretically any Forth that lacks floating point support can have it added pretty quickly. The operations are pretty easy to write. for a 16-bit forth with 32-bit floats you can write a lot of things : FDUP 2DUP;
Where it gets a little harder is how you want to handle the float literals. You have to dig into the implementation specific parts of the outer interpreter (usually INTERPRET) and hook in >FLOAT as a fallback when >NUMBER doesn
You have to dig into the implementation specific parts of the outer interpreter (usually INTERPRET) and hook in >FLOAT as a fallback when >NUMBER doesn't work. (or look for a "." before trying to convert to a float, else try as a double-cell number, then finally as a single cell number)
When I write a Forth compiler I always make the number conversion a vector so the user can extend it easily for floats, DHMS, Ft-inches, or whatever it is they need to work with as literals. If you grab the old vector then it's easy to chain them too.
I've always maintained that more people have implemented Forth than have used it for a project.
That said, I absolutely love Forth. It wasn't really interested in it until I ran across this IOCCC entry: http://www.ioccc.org/1992/buzzard.2.design [ioccc.org] (I'm amazed it's still around!)
It was like a revelation. I highly recommend writing something like that, and seeing how far you can build up the language from within itself.
Some years back, I was able to get blocks and infix expressions working -- with no more cod
#DeleteFacebook.... lol, no need to , facebook keeps deleting me... i can get down with the idea behind it but i have a tingelley spidey sense on "how linux fell for windowstyle and now takes 8 hours to boot on a celeron cpu... there should be options, not one-size-fits-all as decreed by the overlord Satellius
wether you use python on a supercomputer or choose assembler level lingo with no variable names is a choice too although the former makes less sense IF you have that kind of hardware... i suppos
Overly long names are as bad as overly short names though. FortyCharacterColobNames don't really help, as they're just slower to read. Typically, that's a sign of prefixing or suffixing names with a bunch of needless, repetitive crap.
Long class names aren't so bad, unless you're that guy who names every variable with a short name followed by the full class name. Don't be that guy.
}}} Overly long names are as bad as overly short names though. {{{ --- Coding for Windows around the turn of the century was ridiculous with that gawdawful variable naming convention. What was it called, Hungarian notation or something like that?
I have seen that in Java code. >80 char variable names and 2 or 3 chars different between them. Needless to say, the project was later scrapped because if numerous design defects that could not be fixed and constantly caused problems.
Hungarian notation was actually well motivated for its intended use, and then went horribly wrong. First within Microsoft, and then it spread like a disease as people took MS APIs as gospel.
The original intent, which was smart, for for prefixing row variables and column variables in the Excel codebase with rw and co, so that you'd never accidentally try to add or subtract a row and a column. Both types were ints, so this wasn't something the compiler could check for you, nor was the information redundant. Sadly, it was all downhill from there.
The guidelines were given in an attempt to improve coding at Microsoft. It failed. Then the entire book of Code Complete was intended for Microsoft devs so they'd do better, and it failed, but also succeeded in fooling people into thinking it was actually Microsoft's standard coding guidelines.
Not in C. If you want the mathematical operators to work, you've got ints. typdefs don't change that. It's a fundamental failing in most languages that you can't create something that is as easy and efficient to work with as an int, but is treated as a different type.
But Excel was written in C - pre-C99 C for that matter. The horror that Hungarian Notation became was the result of the limited type expressiveness of C.
Pascal, Modula, Oberon, Ada - they all do that. No idea about C++, I have to admit.
OK, but any languages anyone uses in this century? Not saying it's a bad idea, just an abandoned one. There's no easy way in C++, but you can do it with a lot of effort. Maybe worth doing for a row class and a column class in a spreadsheet, but not for more normal use.
You had structs and dedicated functions. That's all that is required. You don't need anymore than that.
Maybe worth doing for a row class and a column class in a spreadsheet, but not for more normal use.
There are plenty of libraries for such uses - like unit libraries in the case of physical calculations.
A row and column class is simple and doesn't require much work.
The point is you're supposed to use dedicated classes to represent independent concepts and its limited set of operations, and that was always the case even back in the C89 days.
You had structs and dedicated functions. That's all that is required. You don't need anymore than that.
Useless for the purpose. Speed matters. Size matters. Doubly so back in the tail end of 16-bit computers, when Excel was first written.
A row and column class is simple and doesn't require much work.
Every problem has a simple, easy to understand, wrong answer.
The point is you're supposed to use dedicated classes to represent independent concepts and its limited set of operations,
The point of software development is first to solve the customer's problem. Fail to do that, and it doesn't matter how pretty your code is as it will never get a new version.
Useless for the purpose. Speed matters. Size matters.
A struct, with a single integer member is too big?
The point of software development is first to solve the customer's problem. Fail to do that, and it doesn't matter how pretty your code
So solving the customer's problem with bugs is a good thing? This is not about prettiness of code. In fact, it's pretty ugly, compared to using an integer. The types aren't there to make it pretty. The types are there to prevent actual bugs. The fact you can't understand this tells me you write pretty shit software.
A struct, with a single integer member is too big?
Yes, typically 2-4 ints in size. Some compilers have pragmas to help, but when ints were 16 bits I don't think it was possible to get that with pragmas (it has been a while). Often stucts are 8-byte aligned, if not 16-byte, to ensure whatever is the first element of the srtuct is aligned.
Also, old compilers simply wouldn't put structs on the stack. Even if you declared the function that way, you'd get a pointer.
So solving the customer's problem with bugs is a good thing? This is not about prettiness of code. In fact, it's pretty ugly, compared to using an integer. The types aren't there to make it pretty. The types are there to prevent actual bugs. The fact you can't understand this tells me you write pretty shit software.
You've simply no familiarity with the sort of constrained environment programming C is appropr
In C++, you'd use operator overloading, but for some strange reason people hate operator overloading even more than Hungarian notation or userspace bugs.
And operator overloading should be used judiciously when it makes sense. So something like adding a row to a column that doesn't make any semantic sense wouldn't have an operator for it.
Yes in C. You just use a struct. The fact that it stops people from using mathematical operations is a good thing because it makes it an error to misuse things with the wrong type. There is no cause for, say, adding a column to a row. If there was, you'd write a simple, named function to do it that makes it immediately obvious what it was doing.
I actually like to believe it comes from a misunderstanding of language. Its originator says "types" in his paper, but actually means "kinds" of variables (i.e. by purpose they fulfill, rather than by what they mean in terms of data typing). E.g.: "int imgWidth, imgHeight; float imgScale;" vs "int winWidth, winHeight; float winZoom;".
You keep the variables that belong to the same logical thing you try to do together - kind of like micro-structures.
Its originator says "types" in his paper, but actually means "kinds" of variables (i.e. by purpose they fulfill, rather than by what they mean in terms of data typing)
Yes! A thousand times this.
The best explanation of the original vision of Hungarian and what's good about it is this essay:
It's a clash between people who get stuff done when coding, and people who'd rather argue for a few months about proper style and coming up with a team standard about precise variable naming. If your function is so long that you need to remind the reader what the variable is being used for on every line, then your function is too long and might be worth breaking it up.
Possibly because 'r' is only being used in a short function. This is why mathemeticians write 'r' on the blckboard (or whiteboard these days), the context is clear. It's when functions get long that the debate starts to grow. Part of the reason many local variable names are long is because the functions are also long and so the context is murky. So r becomes radius, which becomes dRadius because someone wants to denote the type because the declaration was too long ago, and this becomes dCircleRadius, an
But arbitrarily breaking up functions?
You're clearly not concerned with code performance, since apparently long functions need to be broken up Just Because (TM),
you're also not concerned with human code parsing efficiency, because long words are hard for you to type (or are some kind of impediment to your productivity, I assume, since you class users of it as "people who get stuff done")...
but you're so very concerned about typing efficiency.
You seem to want to argue that we should all write
I'm all for going past the 80-char limit, but some limit is still desirable. I maintain my terminals at a 120 character width, which still fits nicely on my display, and then I try to limit my lines to 120 chars.
But this also makes me think that there's a need for a 'statement-based' version of grep, rather than the current line-based one. If vi and every other text processing program these days understands multiple language syntaxes, why not put that knowledge to use. A new grep could optionally search
FortyCharacterColobNames For many people - like me - they are not slower to read, as we read whole words as a symbol more or less instantly. Translation fccn into a meaning full thing requires mental effort for me, though, and slows me down.
8x16 font at 2560x1440 is 320 columns. Very easy to see, plus you can emulate old CGA/EGA/MCGA graphics with just space character and background color.
Meanwhile, for the last 500 years, people have been aware that narrow (newspaper style) columns are easy to read, and A4 (US letter) size paper with (approx) 80 12 point characters was the standard for readability long before the 80 column card was used for text.
I have a 4k screen for coding, but very few of my code files are bigger than 3 A4 pages of text
for readability, not because I used to maintain 3,000 card Fortran using an IBM 026 card punch.
Disclaimer: I did used to type set a hippy newspaper using an IBM Selectric typewriter in the 60s.
You're right, narrow columns improve readability. However, I believe the question we should consider is "is 'readability' in a newspaper and 'readability' in code defined in the same way?".
I think the answer is negative. For example, typefaces with serifs, ligatures and variable widths improve readability, but when it comes to programming - we prefer monospace fonts. Do newspapers come with "dark mode"?:-) Perhaps there are other differences too.
Code is not always read like prose. One could argue that the programmer operates in several modes, each at different levels of abstraction:
(a) high-level: "iterate over a list"
(b) low-level: "this is a for loop that begins at 0 and ends at X, and increments the counter with 1 at each step"
(b) is necessary when you're debugging it, but once the code was written and tested, subsequent reads of it can go at level (a).
For example, this Python chunk would be autoformatted by black ("the uncompromising code formatter"); note that you might have to zoom out a bit to make sure Slashdot doesn't add its own line breaks: for route_id, route_number, name in curs:
result[route_id] = Route(route_id, route_number, name)
result[route_id].stations = self.load_route_stations(route_id)
result[route_id].station_ids = [station.station_id for station in result[route_id].stations]
result[route_id].checkpoints = self.load_route_checkpoints(route_id)
result[route_id].checkpoint_ids = [entry.checkpoint_id for entry in result[route_id].checkpoints]
to:
for route_id, route_number, name in curs:
result[route_id] = Route(route_id, route_number, name)
result[route_id].stations = self.load_route_stations(route_id)
result[route_id].station_ids = [
station.station_id for station in result[route_id].stations
]
result[route_id].checkpoints = self.load_route_checkpoints(route_id)
result[route_id].checkpoint_ids = [
entry.checkpoint_id for entry in result[route_id].checkpoints
]
In the top code excerpt, the programmer sees it as "each line sets an attribute of the object in question", mode (a). Whereas in the bottom excerpt some of these logical operations span across multiple lines and you're forced into mode (b), because you're not sure if these several lines are a part of the same logical operation or not, until you read them.
This reminds me of the "Thinking fast and slow" dichotomy, where "system 1" makes a fast decision, while "system 2" makes a slow one. In my experience, quite often when long lines are broken down into multiple lines I am forced to deal with them using "system 2" when "system 1" would suffice.
So, there are cases when long lines are appropriate.
But they're close, and margin fiddling can make the line and page breaks work. Metric paper sizing is superior not because it's metric, but because of the 1:sqrt(2) ratio of width to height that means you can cut A1 in half and get two A2 sheets, cut them in half and get four A3 sheets, cut them in half and get eight A4 sheets, ad infinitum. Whereas letter and legal and our envelope sizing...
DEC VT200 and newer serial terminals offered a 132-column mode. Best I can figure it was chosen to match the printers of the day (1980s and early 90s).
Once I started using XTerm on a high-resolution RGB monitor in 1989 there was literally no reason to stick with 80 columns anymore. I've never gone back.
The fact that 80 columns is still a recommendation is laughably silly.
Sense at last (Score:5, Interesting)
Artificial limits to the line length is a mistake, it's a totally arbitrary value, and has horrendous knock on effects. People end up choosing bad variable names as otherwise the lines get too long. The intention was to produce readable code that can be viewed and understood, and if that is the intention, then line length should defer to readability, not the other way around.
Re:Sense at last (Score:5, Funny)
Yes! Give me a hard limit of 80 character lines and I'll show you a bunch of 3-letter variable names!
A.
Re: (Score:2)
Re: Sense at last (Score:2)
Don't you mean 962 names?
Re:Sense at last (Score:5, Funny)
How about 1-letter variables? [xkcd.com] (SFW).
Re: (Score:3)
Instead of 1 letter variables, how about store everything on the stack and use color to decide the type [ultratechnology.com] ?
Re: Sense at last (Score:2)
Forth and RPN calculators.
Only headache I had with Forth was the lack of floating point support.
Re: (Score:2)
I had them when I used PygmyForth: F+ F- F* F/ FSIN FCOS FTAN ...
Theoretically any Forth that lacks floating point support can have it added pretty quickly. The operations are pretty easy to write. for a 16-bit forth with 32-bit floats you can write a lot of things : FDUP 2DUP ;
Where it gets a little harder is how you want to handle the float literals. You have to dig into the implementation specific parts of the outer interpreter (usually INTERPRET) and hook in >FLOAT as a fallback when >NUMBER doesn
Re: (Score:3)
You have to dig into the implementation specific parts of the outer interpreter (usually INTERPRET) and hook in >FLOAT as a fallback when >NUMBER doesn't work. (or look for a "." before trying to convert to a float, else try as a double-cell number, then finally as a single cell number)
When I write a Forth compiler I always make the number conversion a vector so the user can extend it easily for floats, DHMS, Ft-inches, or whatever it is they need to work with as literals. If you grab the old vector then it's easy to chain them too.
Re: (Score:1)
I wrote a forth interperter (in assembly with guidence from a book) that worked. But never actually got the language itself.
Re: (Score:2)
I've always maintained that more people have implemented Forth than have used it for a project.
That said, I absolutely love Forth. It wasn't really interested in it until I ran across this IOCCC entry: http://www.ioccc.org/1992/buzzard.2.design [ioccc.org] (I'm amazed it's still around!)
It was like a revelation. I highly recommend writing something like that, and seeing how far you can build up the language from within itself.
Some years back, I was able to get blocks and infix expressions working -- with no more cod
Re: (Score:2)
Forth.
I enjoyed forth back in the day, when 'putering was a hobby and not a significant part of my vocation.
It was, and still is, the best write-only language ever!
And The Inspiration for Yoda talk it was.
Re: Sense at last (Score:2)
Bumper Sticker:
Forth 3 if honk then
Re: Sense at last (Score:2)
(ASCII heart showed up as a 3)
Re: Sense at last (Score:2)
I c d jk u mk
Re: (Score:1)
i can get down with the idea behind it but i have a tingelley spidey sense on "how linux fell for windowstyle and now takes 8 hours to boot on a celeron cpu
wether you use python on a supercomputer or choose assembler level lingo with no variable names is a choice too although the former makes less sense IF you have that kind of hardware
Re: (Score:2)
Overly long names are as bad as overly short names though. FortyCharacterColobNames don't really help, as they're just slower to read. Typically, that's a sign of prefixing or suffixing names with a bunch of needless, repetitive crap.
Long class names aren't so bad, unless you're that guy who names every variable with a short name followed by the full class name. Don't be that guy.
Re: (Score:2)
Re:Sense at last (Score:4, Interesting)
I have seen that in Java code. >80 char variable names and 2 or 3 chars different between them. Needless to say, the project was later scrapped because if numerous design defects that could not be fixed and constantly caused problems.
Re:Sense at last (Score:5, Informative)
Hungarian notation was actually well motivated for its intended use, and then went horribly wrong. First within Microsoft, and then it spread like a disease as people took MS APIs as gospel.
The original intent, which was smart, for for prefixing row variables and column variables in the Excel codebase with rw and co, so that you'd never accidentally try to add or subtract a row and a column. Both types were ints, so this wasn't something the compiler could check for you, nor was the information redundant. Sadly, it was all downhill from there.
Re: (Score:1)
The guidelines were given in an attempt to improve coding at Microsoft. It failed. Then the entire book of Code Complete was intended for Microsoft devs so they'd do better, and it failed, but also succeeded in fooling people into thinking it was actually Microsoft's standard coding guidelines.
Re: (Score:2)
Both types were ints, so this wasn't something the compiler could check for you,
Except it could - by making the concepts different types. That's what types are for, and was possible even back then.
Re: (Score:2)
Not in C. If you want the mathematical operators to work, you've got ints. typdefs don't change that. It's a fundamental failing in most languages that you can't create something that is as easy and efficient to work with as an int, but is treated as a different type.
Re: (Score:2)
Pascal, Modula, Oberon, Ada - they all do that. No idea about C++, I have to admit.
Re: (Score:2)
But Excel was written in C - pre-C99 C for that matter. The horror that Hungarian Notation became was the result of the limited type expressiveness of C.
Pascal, Modula, Oberon, Ada - they all do that. No idea about C++, I have to admit.
OK, but any languages anyone uses in this century? Not saying it's a bad idea, just an abandoned one. There's no easy way in C++, but you can do it with a lot of effort. Maybe worth doing for a row class and a column class in a spreadsheet, but not for more normal use.
Re: (Score:2)
Maybe worth doing for a row class and a column class in a spreadsheet, but not for more normal use.
There are plenty of libraries for such uses - like unit libraries in the case of physical calculations.
A row and column class is simple and doesn't require much work.
The point is you're supposed to use dedicated classes to represent independent concepts and its limited set of operations, and that was always the case even back in the C89 days.
Re: (Score:2)
You had structs and dedicated functions. That's all that is required. You don't need anymore than that.
Useless for the purpose. Speed matters. Size matters. Doubly so back in the tail end of 16-bit computers, when Excel was first written.
A row and column class is simple and doesn't require much work.
Every problem has a simple, easy to understand, wrong answer.
The point is you're supposed to use dedicated classes to represent independent concepts and its limited set of operations,
The point of software development is first to solve the customer's problem. Fail to do that, and it doesn't matter how pretty your code is as it will never get a new version.
Re: (Score:2)
Useless for the purpose. Speed matters. Size matters.
A struct, with a single integer member is too big?
The point of software development is first to solve the customer's problem. Fail to do that, and it doesn't matter how pretty your code
So solving the customer's problem with bugs is a good thing? This is not about prettiness of code. In fact, it's pretty ugly, compared to using an integer. The types aren't there to make it pretty. The types are there to prevent actual bugs. The fact you can't understand this tells me you write pretty shit software.
Re: (Score:2)
A struct, with a single integer member is too big?
Yes, typically 2-4 ints in size. Some compilers have pragmas to help, but when ints were 16 bits I don't think it was possible to get that with pragmas (it has been a while). Often stucts are 8-byte aligned, if not 16-byte, to ensure whatever is the first element of the srtuct is aligned.
Also, old compilers simply wouldn't put structs on the stack. Even if you declared the function that way, you'd get a pointer.
So solving the customer's problem with bugs is a good thing? This is not about prettiness of code. In fact, it's pretty ugly, compared to using an integer. The types aren't there to make it pretty. The types are there to prevent actual bugs. The fact you can't understand this tells me you write pretty shit software.
You've simply no familiarity with the sort of constrained environment programming C is appropr
Re: (Score:2)
Re: (Score:2)
And operator overloading should be used judiciously when it makes sense. So something like adding a row to a column that doesn't make any semantic sense wouldn't have an operator for it.
Re: (Score:2)
That's what having a type system is for.
Re: Sense at last (Score:3)
I actually like to believe it comes from a misunderstanding of language. Its originator says "types" in his paper, but actually means "kinds" of variables (i.e. by purpose they fulfill, rather than by what they mean in terms of data typing). E.g.: "int imgWidth, imgHeight; float imgScale;" vs "int winWidth, winHeight; float winZoom;".
You keep the variables that belong to the same logical thing you try to do together - kind of like micro-structures.
Re: (Score:2)
Its originator says "types" in his paper, but actually means "kinds" of variables (i.e. by purpose they fulfill, rather than by what they mean in terms of data typing)
Yes! A thousand times this.
The best explanation of the original vision of Hungarian and what's good about it is this essay:
https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/ [joelonsoftware.com]
I spent some time as a very junior guy working in the Apps group at Microsoft and I will say without apology that I actually like Apps Hungarian.
When
Re: (Score:2)
It's a clash between people who get stuff done when coding, and people who'd rather argue for a few months about proper style and coming up with a team standard about precise variable naming. If your function is so long that you need to remind the reader what the variable is being used for on every line, then your function is too long and might be worth breaking it up.
Re: (Score:2)
If your variable name is // radius
double r;
See the comment?
Then why for funk sake is it not:
double radius?
Obviously over a short piece of text it does not matter.
But how do yo search for variables that means "radius" when the hint is only in comments?
And it is indeed a mental process - that tires you - to convert a random variable name, even if it is obvious - into its meaning all the time.
Re: (Score:2)
Possibly because 'r' is only being used in a short function. This is why mathemeticians write 'r' on the blckboard (or whiteboard these days), the context is clear. It's when functions get long that the debate starts to grow. Part of the reason many local variable names are long is because the functions are also long and so the context is murky. So r becomes radius, which becomes dRadius because someone wants to denote the type because the declaration was too long ago, and this becomes dCircleRadius, an
Re: (Score:2)
and this becomes dCircleRadiusRef
Perfect.
But arbitrarily breaking up functions?
You're clearly not concerned with code performance, since apparently long functions need to be broken up Just Because (TM),
you're also not concerned with human code parsing efficiency, because long words are hard for you to type (or are some kind of impediment to your productivity, I assume, since you class users of it as "people who get stuff done")...
but you're so very concerned about typing efficiency.
You seem to want to argue that we should all write
Re: (Score:2)
I'm all for going past the 80-char limit, but some limit is still desirable. I maintain my terminals at a 120 character width, which still fits nicely on my display, and then I try to limit my lines to 120 chars.
But this also makes me think that there's a need for a 'statement-based' version of grep, rather than the current line-based one. If vi and every other text processing program these days understands multiple language syntaxes, why not put that knowledge to use. A new grep could optionally search
Re:Sense at last (Score:4, Informative)
FortyCharacterColobNames
For many people - like me - they are not slower to read, as we read whole words as a symbol more or less instantly.
Translation fccn into a meaning full thing requires mental effort for me, though, and slows me down.
Re: (Score:2)
Re: (Score:2)
Well, since I have seen 100 char variable names (3 char difference sometimes) in Java _production_ code, I do not agree.
Re: (Score:3)
Re: (Score:2)
8x16 font at 2560x1440 is 320 columns. Very easy to see, plus you can emulate old CGA/EGA/MCGA graphics with just space character and background color.
Re:Sense at last (Score:5, Interesting)
Possibly, in an Egyptian pyramid.
Meanwhile, for the last 500 years, people have been aware that narrow (newspaper style) columns are easy to read, and A4 (US letter) size paper with (approx) 80 12 point characters was the standard for readability long before the 80 column card was used for text.
I have a 4k screen for coding, but very few of my code files are bigger than 3 A4 pages of text for readability, not because I used to maintain 3,000 card Fortran using an IBM 026 card punch.
Disclaimer: I did used to type set a hippy newspaper using an IBM Selectric typewriter in the 60s.
Re:Sense at last (Score:5, Insightful)
You're right, narrow columns improve readability. However, I believe the question we should consider is "is 'readability' in a newspaper and 'readability' in code defined in the same way?".
I think the answer is negative. For example, typefaces with serifs, ligatures and variable widths improve readability, but when it comes to programming - we prefer monospace fonts. Do newspapers come with "dark mode"? :-) Perhaps there are other differences too.
Code is not always read like prose. One could argue that the programmer operates in several modes, each at different levels of abstraction:
(b) is necessary when you're debugging it, but once the code was written and tested, subsequent reads of it can go at level (a).
For example, this Python chunk would be autoformatted by black ("the uncompromising code formatter"); note that you might have to zoom out a bit to make sure Slashdot doesn't add its own line breaks:
for route_id, route_number, name in curs:
result[route_id] = Route(route_id, route_number, name)
result[route_id].stations = self.load_route_stations(route_id)
result[route_id].station_ids = [station.station_id for station in result[route_id].stations]
result[route_id].checkpoints = self.load_route_checkpoints(route_id)
result[route_id].checkpoint_ids = [entry.checkpoint_id for entry in result[route_id].checkpoints]
to:
for route_id, route_number, name in curs:
result[route_id] = Route(route_id, route_number, name)
result[route_id].stations = self.load_route_stations(route_id)
result[route_id].station_ids = [
station.station_id for station in result[route_id].stations
]
result[route_id].checkpoints = self.load_route_checkpoints(route_id)
result[route_id].checkpoint_ids = [
entry.checkpoint_id for entry in result[route_id].checkpoints
]
In the top code excerpt, the programmer sees it as "each line sets an attribute of the object in question", mode (a). Whereas in the bottom excerpt some of these logical operations span across multiple lines and you're forced into mode (b), because you're not sure if these several lines are a part of the same logical operation or not, until you read them.
This reminds me of the "Thinking fast and slow" dichotomy, where "system 1" makes a fast decision, while "system 2" makes a slow one. In my experience, quite often when long lines are broken down into multiple lines I am forced to deal with them using "system 2" when "system 1" would suffice.
So, there are cases when long lines are appropriate.
Re: (Score:2)
Actually length of lines makes no difference for me in "easy to read".
I never believed such claims or studies - but I never conducted a study, so no idea.
Re: (Score:2)
Not to be "that guy" but US Letter paper is not the same dimensions as A4.
US Letter: 8.5 by 11 inches (approx. 21.5 cm by 27.9 cm)
A4 paper: approx. 8.27 inches by 11.75 inches (21 cm by 29.7 cm)
Re: (Score:2)
Re: (Score:2)
8x16 font at 2560x1440 is 320 columns. Very easy to see
What a truly bizarre claim, as if raw pixel sizes had any bearing on visibility.
Re: Sense at last (Score:2)
The point overall is to avoid hard arbitrary constraints. As long as the code is readable it's good.
Re: (Score:2)
DEC VT200 and newer serial terminals offered a 132-column mode. Best I can figure it was chosen to match the printers of the day (1980s and early 90s).
Once I started using XTerm on a high-resolution RGB monitor in 1989 there was literally no reason to stick with 80 columns anymore. I've never gone back.
The fact that 80 columns is still a recommendation is laughably silly.
Re: (Score:1)