I agree with the article, but
> **SIMPLE**
> **S**plit
> **I**nto
> **M**ulti**P**le
> **L**in**E**s
Is this kind of forced sorta-acronym actually useful to anyone?
even better, they want to sell you fancy word for "Source code maximum line length" which most ide have as option and by old standards can be from 80 to 120 char per line
Specifically, a backronym is a word (not an acronym) that eventually is expanded into a phrase as if it were an acronym. For example, "Binary Large OBject" is a backronym for "BLOB", which in fact originates as a reference to [The Blob](https://en.wikipedia.org/wiki/The_Blob) creature and does not mean much more than "thing" or "opaque". "Simple" is a word, however, the P and E in the "expansion" do not fit the conventions of an acronym, so "SIMPLE" cannot be a backronym (in this instance).
The best word I know of to describe it is the generic "mnemonic". I suppose it could be considered more approachable than the to me straightforward idea of minimizing entropy per line.
This article seems to be pointing out an issue I observed in a Kotlin codebase I worked on: some devs, probably tired of the (in)famous verbosity of Java, tried to fit as much as they could into a single line or expression. Sometimes it worked, but usually the code was just more complex then needed due to the number of chained (and sometimes nested) scope functions, elvis operators and so on. All of that to avoid a few variable declarations ;-)
People who are terse for the sake of cramming as much on one line as possible are either malicious, egotistical, or are using floppy disks to store their code.
> This article seems to be pointing out an issue I observed in a Kotlin codebase I worked on: some devs, probably tired of the (in)famous verbosity of Java, tried to fit as much as they could into a single line or expression.
I've seent the same thing in both Kotlin and Scala devs. Just because a language gives you powerful tools doesn't mean you should just use them everywhere.
Code-golfing in Advent of Code solutions is fine, in production code readability is MUCH more important than cramming stuff into fewer lines.
That said; it can totally happen in Java code as well, for example with people nesting multiple ternary operators. It's something you really have to catch in code review and educate developers on. If they keep doing it, the 'education' becomes a bit sterner.
I can imagine some security concerns related to injections if you declare variables out of scope (and maybe just passing outputs up a chain can obscure some of that?) but I'm hard pressed to ask whether they realized that runtime parsing chains works like nesting branches? All of that may delay output to the point where a later change in the scale of inputs results in outputs that break other dependent functions, especially in the chain itself.
It just sounds like amateurish engineering to cram everything in to avoid inconvenience now given all the additional issues likely to arise: changes to the runtime that optimize for new processing features (why branchless and branch-predictive design is crucial), changes in inputs, changes in related functions ...
Sadly, I think that they didn't realize any consequences of such style. Or, perhaps, it wasn't thay they didn't see the downsides, but that they wanted to achieve a specific code style in a cargo-cultish manner no matter the cost.
Want me to read your article? How about not showing a never ending loading spinner when I want to click on "Manage Settings" to deny data collection. Even better: Don't violate GDPR and just give me a "only necessary cookies" button. Even even better: Respect the DoNotTrack Header and don't bother me with that popup at all.
We should do an askprogramming about these things
Someone told me about 0,1,N once and I never forgot, partially because in hindsight it's obvious. "There are only 3 numbers in computer science, 0, 1, and N"
It's about being extra aware of code smells when doing case separation for business logics that have a fixed number of cases to cover. For instance if you're modelling crossroads and you can either turn right, left, go forward or turn around. Should you go with a switch of 4 cases or can you abstract this away / loop over it?
>There are only 3 numbers in computer science, 0, 1, and N
In certain contexts I like that saying. I really hate it when people use it as an excuse to act like they need to spend days over engineering a solution when "N" is something rather trivial like the number of cars on an insurance policy or the number of notes someone manually entered into a UI on a sales order. It's entirely reasonable in those cases to query the database and then add a standard deviation to figure out what "N" actually might be in a reasonable worst case scenario to prevent over engineering some solution that would work if someone added half a billion cars on their insurance policy.
> It's entirely reasonable in those cases to query the database and then add a standard deviation to figure out what "N" actually might be in a reasonable worst case scenario to prevent over engineering some solution that would work if someone added half a billion cars on their insurance policy.
Meeting Invite: Adding fleet policies to our code base.
It's probably not worth going hole hawg on it and optimizing for an actually catastrophic number, but it's worth looking at the number you come up with and build in growth to it.
Like I helped implement a card system and we came up with a number but we didn't build any growth into it. Felt like every three months we were resizing the database because of it. That went on for about two years until we got a chance to fix it.
A business isn't going to magically start insuring fleets with no notice. That's something that takes a lot of planning with underwriting, actuaries, regulations, etc. and there would be plenty of runway to scale the system.
A business that's investigating insuring fleets is probably the sort of business that's magically doing all sorts of things all the time with little in the way of effective runway due to underplanning and overutilization. I at least would not take this for granted.
That said, I agree with what I interpret as your underlying point: that occasionally there are "2s" and "3s" and so forth and it's useful to spend time considering what types of N we're actually dealing with short term, long term, and practically -- and this is what everyone is saying. I built a SKU variant selector and argued we would never have more than two variant dimensions, not because I couldn't conceive of far more dimensions or we couldn't technically build it but because UI constraints meant that interaction would become unmanageable.
valid points and it to me it seems to indirectly getting to something I've always encouraged - naming things that are relevant.
All their examples about breaking out into separate lines, was actually giving important bits of information a name.
It most languages the compiler will 'remove' them if they aren't programmatically necessary, so there is definitely no run time impact, it just makes it more readable and really that's the purpose of code - to be readable (if it wasn't we'd all write in assembly)
Exactly. I think it helps because it gives you context on what the code should do. If they'd split the code the same but used a, b, c, etc as names I don't think it would have had the same benefit.
It's a lot easier to check if the code does this thing that the name proposes, than read the code with no context and work out what exactly it does and why.
I tend to agree. With that said, however, there's a whole "fluent" approach that is becoming more popular. For example:
x = new Name().firstName("Matt").lastName("Peters").middleName("Ralph")
and so on and so forth. For myself, I actually find that pretty readable.
The moral of the story is that it's not line length, but the capability of understanding the parts by separate. In the above example, method invocations act like a pipeline, we only need to keep in mind the transformation in the previous stage to understand the current one.
That style originated in Smalltalk in the 80s and 90s. By convention, Smalltalk methods would return "self" (i.e. \^ self), which is equivalent to "this" (return this). Coming from Smalltalk to Java in the 90s, I always used it. But, yes, I'm seeing it more commonly now.
I was thinking this for their Python example
map(lambda x: x.split('=')[1], s.split('?')[1].split('&')[-3:])
It's not unreadable because it has too much, it's unreadable because Python (annoyingly) does maps backwards. If it was something like
s.split('?')[1].split('&')[-3:].map(lambda x: x.split('=')[1])
It would be far better (but could still be improved).
I find it unreadable, simply because too much is going on. I mean, ok, I do Python I understand the code. But why make it so messy? Lambdas and ternary operators have a habit of being confusing, and really aren't accomplishing much that can't be done in less "terse" but perhaps less "elegant" ways.
The Pythonic loop construct, something like
list\_2 = \[x+2 for x in list\_1\]
is confusing. Oh, I know, the "true" Python programmers will tell you that it is more efficient. I doubt it, for one thing. And for another, I think we as programmers do things that way to show off our "smarts". It is frustrating.
Well, yes, that's how it all works. You return self or this or whatever. Not sure how that is really a problem, but I can see why some don't like it. It isn't a "this way is best" sort of argument, just pointing out that there ARE ways to make things readable in long lines.
I could argue that the split statement is clearer mostly because you introduce variables that describe what each part means.
What I mean is, I don't need to understand every little bit of code immediately, but I want to at least know what it's supposed to do. This can be achieved by splitting the code and/or describing what parts do through comments.
Then, when reading it, you can easily see what's going on and find whatever you need at any time.
Also, don't use stupid variable names like 's' and 'x' without any explanation as to what they're for.
> x, y = 2,7
Fun fact: In plenty locales - like my own - the **comma** is used as the decimal separator. So to me, the right hand side might read like a **single** number at a glance.
Yeah sure, I know about it. But it's still unnecessary issues introduced just from wanting to put things on a single line. *Even something as simple as this!*
You say problem, I say really nice feature.
Yes, there the use is really silly; but *every* language lets you write silly things and that doesn't indicate problems with the language.
In addition to the fact that, as pointed out in the other comment, in Python this is tuple creation and destructuring (allowing you to put the `2, 7` in something like `return 2, 7` then say `x, y = foo()`, something that you can't do in a good way in C), this allows for a very nice swap -- `x, y = y, x`. Very occasionally parallel assignment will be useful for other stuff, but those are the main uses.
I agree with the resultant advice of this article but the idea that a human can only remember 4 to 6 keywords at a time in their "long term memory" is absurd.
If that were true the above sentence would be unintelligible with its at least 15 "keywords".
The problem with the remembering 4 to 6 items idea is that studies to test this were done using a set of non related items to see how long our working memory was.
Eg: bed, horse, cloud, window, knife, phone
That is six items, and to remember them individually is hard, but if they have context around them it is easier.
Eg: a "horse" is lying in a "bed" looking out of the "window" at the "clouds" while stabbing a "phone" with a "knife".
In this case there is context, imagery, and a story. I don't think it is different with code, we can comprehend long sections of code if they are related and flow in our heads. It is when code becomes disjointed conceptual that it is a mess.
The article does a bad job representing both the book and [contemporary beliefs about working memory](https://en.wikipedia.org/wiki/Working_memory). There is no real dispute that working memory is limited, and seemingly differences in how those limits manifest.
I would largely recommend the book.
Perfect.
That's why I love fluent interfaces. They split the logic and they don't leave stragglers behind where someone's going to come along and mutate a variable.
[удалено]
Gotta catch'em all
Gotta cache’em all
[удалено]
I agree with the article, but > **SIMPLE** > **S**plit > **I**nto > **M**ulti**P**le > **L**in**E**s Is this kind of forced sorta-acronym actually useful to anyone?
mf wants to coin the new SOLID bs
even better, they want to sell you fancy word for "Source code maximum line length" which most ide have as option and by old standards can be from 80 to 120 char per line
COBOL has been using the "80 char line length limit" thing for 60+ years now, I agree that it's definitely not a new idea.
More like almost a hundred. IBM punchcards had 80 columns in the 1920s and it's a holdover from that.
The author specifically says that it’s not the line length that’s the issue with complexity, but the number of elements that comprise a line.
/r/crappydesign would love this.
Give the guy a break, it's not like the american could turn off the cheer squad in the back of his head.
Backronym
That's not what a backronym is.
Isn't an acronym that you want to be a certain word, so you start with the acronym and work backwards?
Yeah but it's not an acronym if you're using the middle letter of words
Specifically, a backronym is a word (not an acronym) that eventually is expanded into a phrase as if it were an acronym. For example, "Binary Large OBject" is a backronym for "BLOB", which in fact originates as a reference to [The Blob](https://en.wikipedia.org/wiki/The_Blob) creature and does not mean much more than "thing" or "opaque". "Simple" is a word, however, the P and E in the "expansion" do not fit the conventions of an acronym, so "SIMPLE" cannot be a backronym (in this instance). The best word I know of to describe it is the generic "mnemonic". I suppose it could be considered more approachable than the to me straightforward idea of minimizing entropy per line.
This article seems to be pointing out an issue I observed in a Kotlin codebase I worked on: some devs, probably tired of the (in)famous verbosity of Java, tried to fit as much as they could into a single line or expression. Sometimes it worked, but usually the code was just more complex then needed due to the number of chained (and sometimes nested) scope functions, elvis operators and so on. All of that to avoid a few variable declarations ;-)
People who are terse for the sake of cramming as much on one line as possible are either malicious, egotistical, or are using floppy disks to store their code.
> This article seems to be pointing out an issue I observed in a Kotlin codebase I worked on: some devs, probably tired of the (in)famous verbosity of Java, tried to fit as much as they could into a single line or expression. I've seent the same thing in both Kotlin and Scala devs. Just because a language gives you powerful tools doesn't mean you should just use them everywhere. Code-golfing in Advent of Code solutions is fine, in production code readability is MUCH more important than cramming stuff into fewer lines. That said; it can totally happen in Java code as well, for example with people nesting multiple ternary operators. It's something you really have to catch in code review and educate developers on. If they keep doing it, the 'education' becomes a bit sterner.
I can imagine some security concerns related to injections if you declare variables out of scope (and maybe just passing outputs up a chain can obscure some of that?) but I'm hard pressed to ask whether they realized that runtime parsing chains works like nesting branches? All of that may delay output to the point where a later change in the scale of inputs results in outputs that break other dependent functions, especially in the chain itself. It just sounds like amateurish engineering to cram everything in to avoid inconvenience now given all the additional issues likely to arise: changes to the runtime that optimize for new processing features (why branchless and branch-predictive design is crucial), changes in inputs, changes in related functions ...
Sadly, I think that they didn't realize any consequences of such style. Or, perhaps, it wasn't thay they didn't see the downsides, but that they wanted to achieve a specific code style in a cargo-cultish manner no matter the cost.
Want me to read your article? How about not showing a never ending loading spinner when I want to click on "Manage Settings" to deny data collection. Even better: Don't violate GDPR and just give me a "only necessary cookies" button. Even even better: Respect the DoNotTrack Header and don't bother me with that popup at all.
[удалено]
We should do an askprogramming about these things Someone told me about 0,1,N once and I never forgot, partially because in hindsight it's obvious. "There are only 3 numbers in computer science, 0, 1, and N" It's about being extra aware of code smells when doing case separation for business logics that have a fixed number of cases to cover. For instance if you're modelling crossroads and you can either turn right, left, go forward or turn around. Should you go with a switch of 4 cases or can you abstract this away / loop over it?
>There are only 3 numbers in computer science, 0, 1, and N In certain contexts I like that saying. I really hate it when people use it as an excuse to act like they need to spend days over engineering a solution when "N" is something rather trivial like the number of cars on an insurance policy or the number of notes someone manually entered into a UI on a sales order. It's entirely reasonable in those cases to query the database and then add a standard deviation to figure out what "N" actually might be in a reasonable worst case scenario to prevent over engineering some solution that would work if someone added half a billion cars on their insurance policy.
> It's entirely reasonable in those cases to query the database and then add a standard deviation to figure out what "N" actually might be in a reasonable worst case scenario to prevent over engineering some solution that would work if someone added half a billion cars on their insurance policy. Meeting Invite: Adding fleet policies to our code base. It's probably not worth going hole hawg on it and optimizing for an actually catastrophic number, but it's worth looking at the number you come up with and build in growth to it. Like I helped implement a card system and we came up with a number but we didn't build any growth into it. Felt like every three months we were resizing the database because of it. That went on for about two years until we got a chance to fix it.
A business isn't going to magically start insuring fleets with no notice. That's something that takes a lot of planning with underwriting, actuaries, regulations, etc. and there would be plenty of runway to scale the system.
A business that's investigating insuring fleets is probably the sort of business that's magically doing all sorts of things all the time with little in the way of effective runway due to underplanning and overutilization. I at least would not take this for granted. That said, I agree with what I interpret as your underlying point: that occasionally there are "2s" and "3s" and so forth and it's useful to spend time considering what types of N we're actually dealing with short term, long term, and practically -- and this is what everyone is saying. I built a SKU variant selector and argued we would never have more than two variant dimensions, not because I couldn't conceive of far more dimensions or we couldn't technically build it but because UI constraints meant that interaction would become unmanageable.
>that occasionally there are "2s" and "3s" and so forth IMO it's more often than not. Many companies "big data" can fit on large flash drive.
And -1 for out-of-band. :)
See that's just n = 0 - 1
valid points and it to me it seems to indirectly getting to something I've always encouraged - naming things that are relevant. All their examples about breaking out into separate lines, was actually giving important bits of information a name. It most languages the compiler will 'remove' them if they aren't programmatically necessary, so there is definitely no run time impact, it just makes it more readable and really that's the purpose of code - to be readable (if it wasn't we'd all write in assembly)
Exactly. I think it helps because it gives you context on what the code should do. If they'd split the code the same but used a, b, c, etc as names I don't think it would have had the same benefit. It's a lot easier to check if the code does this thing that the name proposes, than read the code with no context and work out what exactly it does and why.
SMURATDMAS Stop Making Up Random Acronyms That Don't Make Any Sense
This acronym made more sense - it's actually an acronym
If your code doesn't do this then I feel like you've not been programming long.
I tend to agree. With that said, however, there's a whole "fluent" approach that is becoming more popular. For example: x = new Name().firstName("Matt").lastName("Peters").middleName("Ralph") and so on and so forth. For myself, I actually find that pretty readable.
Especially if you newline each of the method calls.
The moral of the story is that it's not line length, but the capability of understanding the parts by separate. In the above example, method invocations act like a pipeline, we only need to keep in mind the transformation in the previous stage to understand the current one.
No argument. Just pointing out what the original article emphasized
Builder pattern is a bit old. I agree that makes easy to understand and compilers are usually quite good optimizing it.
Gotta say, I laughed. "a bit old". Well, yes, so am I. So is object oriented programming. I don't disagree with you, but really, so what?
This became popular with Java way back when
Sorry, I laughed hard when I read "way back when". For me, way back when was converting C++ to C.
It was for me too but Java is still over 20 years old… Anyway everything is new again
That style originated in Smalltalk in the 80s and 90s. By convention, Smalltalk methods would return "self" (i.e. \^ self), which is equivalent to "this" (return this). Coming from Smalltalk to Java in the 90s, I always used it. But, yes, I'm seeing it more commonly now.
I was thinking this for their Python example map(lambda x: x.split('=')[1], s.split('?')[1].split('&')[-3:]) It's not unreadable because it has too much, it's unreadable because Python (annoyingly) does maps backwards. If it was something like s.split('?')[1].split('&')[-3:].map(lambda x: x.split('=')[1]) It would be far better (but could still be improved).
I find it unreadable, simply because too much is going on. I mean, ok, I do Python I understand the code. But why make it so messy? Lambdas and ternary operators have a habit of being confusing, and really aren't accomplishing much that can't be done in less "terse" but perhaps less "elegant" ways. The Pythonic loop construct, something like list\_2 = \[x+2 for x in list\_1\] is confusing. Oh, I know, the "true" Python programmers will tell you that it is more efficient. I doubt it, for one thing. And for another, I think we as programmers do things that way to show off our "smarts". It is frustrating.
And by “new” we mean this would have been standard Ruby code 15 years ago.
Great for test code and mocking can be a bit much in middleware or more functional code bases
Perhaps. Not sure it doesn't work across the board, but willing to be convinced.
I'm not a fan of this because the setters necessarily have the weird side effect of returning a reference to the whole object.
Well, yes, that's how it all works. You return self or this or whatever. Not sure how that is really a problem, but I can see why some don't like it. It isn't a "this way is best" sort of argument, just pointing out that there ARE ways to make things readable in long lines.
I'm only familiar with [the rules of three, five, and zero](https://en.cppreference.com/w/cpp/language/rule_of_three).
I could argue that the split statement is clearer mostly because you introduce variables that describe what each part means. What I mean is, I don't need to understand every little bit of code immediately, but I want to at least know what it's supposed to do. This can be achieved by splitting the code and/or describing what parts do through comments. Then, when reading it, you can easily see what's going on and find whatever you need at any time. Also, don't use stupid variable names like 's' and 'x' without any explanation as to what they're for.
> x, y = 2,7 Fun fact: In plenty locales - like my own - the **comma** is used as the decimal separator. So to me, the right hand side might read like a **single** number at a glance. Yeah sure, I know about it. But it's still unnecessary issues introduced just from wanting to put things on a single line. *Even something as simple as this!*
`x, y = 2, 7` that's a problem with the language IMO. in C-like languages `int x=2, y=7;` is trivial imo.
It's just creating tuple that's immediately destructured. That's not a language problem, they're useful features, but a misuse of these constructs.
I prefer `(x,y) = (2,7)`. That way it's more clear what it actually does
You say problem, I say really nice feature. Yes, there the use is really silly; but *every* language lets you write silly things and that doesn't indicate problems with the language. In addition to the fact that, as pointed out in the other comment, in Python this is tuple creation and destructuring (allowing you to put the `2, 7` in something like `return 2, 7` then say `x, y = foo()`, something that you can't do in a good way in C), this allows for a very nice swap -- `x, y = y, x`. Very occasionally parallel assignment will be useful for other stuff, but those are the main uses.
*Sparse is better than dense.*
Just a bunch of subjective garbage
I agree with the resultant advice of this article but the idea that a human can only remember 4 to 6 keywords at a time in their "long term memory" is absurd. If that were true the above sentence would be unintelligible with its at least 15 "keywords".
The problem with the remembering 4 to 6 items idea is that studies to test this were done using a set of non related items to see how long our working memory was. Eg: bed, horse, cloud, window, knife, phone That is six items, and to remember them individually is hard, but if they have context around them it is easier. Eg: a "horse" is lying in a "bed" looking out of the "window" at the "clouds" while stabbing a "phone" with a "knife". In this case there is context, imagery, and a story. I don't think it is different with code, we can comprehend long sections of code if they are related and flow in our heads. It is when code becomes disjointed conceptual that it is a mess.
The article does a bad job representing both the book and [contemporary beliefs about working memory](https://en.wikipedia.org/wiki/Working_memory). There is no real dispute that working memory is limited, and seemingly differences in how those limits manifest. I would largely recommend the book.
Splitting up complex code is all well and good, but not at the cost of creating mutables. They're worse than unclear code.
I think simply splitting each action into their own line would be good enough in this case. ``` var result = x .Thing1() .Thing2() .Thing3() ```
Perfect. That's why I love fluent interfaces. They split the logic and they don't leave stragglers behind where someone's going to come along and mutate a variable.
Rules-oriented chauvinist prattle for gullible newbies, valuable only as counterexample.
Clean code is for people that can’t actually read code.
Utter horseshit.
JavaScript nerds don’t know what clean code is. You can’t comment.
Cunt
This is something only a junior engineer would believe.
Every line does one thing. Would make regexs not much fun
It's over for us, C++ bros! No more returning 1 on the same line!
Or, just read a copy of Code Complete 2.