As other people have noted, this seems like a criticism of expression-heavy languages. I'm not sure the working memory idea really is a good argument for short lines. Assembly language is entirely short statements, and has only a few operands per line, but is so tedious to read because of how much state/working memory is occupied. Complex expressions can actually reduce the mental overhead by reducing the number of used variables to a minimum.
Want cleaner code? Use the rule of six
251–260 of 352 posts
Re: Want cleaner code? Use the rule of six
#252Earlier quoted context omitted.
That’s nice, but it just highlights that the coding style isn’t sufficiently intelligible by itself. We can’t and shouldn’t rely on a static analyzer to be active to make code intelligible everywhere code is displayed (pull requests, diffs, ...). Doing so favors writing code over reading code, which is generally the wrong bias. Editor support is appropriate and useful to help writing readable code, but it’s bad for e…
One way I try to solve that problem in Rust: use repeated `let thing = simple.invocation();`. No need to rename the variable `thing` if not neccessary. Rust allows redefining a variable with the same name. Additionally I sometimes give the thing a type which makes it even more explicit. Something like this: let thing: Thing = source.prepare(); let thing = thing.make_iterator(); let (first, second) = thing.split(); le…
oof
Re: Want cleaner code? Use the rule of six
#253Earlier quoted context omitted.
Emphasis on well-named. Naming things is hard. Maybe not relevant in simple toy examples, but you don't have to look far until to find a function that isn't so easy to name.
> Naming things is hard Naming is hard unless you have a sensible concept hierarchy, and then naming is easy. Concept hierarchies are hard, unless you have a sensible system model, and then concept hierarchies are easy. System models are hard, unless you have domain expertise, and then system models are easy.
[deleted]
Re: Want cleaner code? Use the rule of six
#254Earlier quoted context omitted.
Short names are easier to read, because they fit on fewer lines. Doubly so if the statement fits on one line.
Shorter names aren't easier to read if you have several similar names used in close proximity. More characters can reduce the congruence and make it easier to differtiate between names. I agree about fitting things onto one line though. It's usually better to break things up into to several short one line steps rather than have a long multi line statement.
More characters can make it harder to differentiate names. The longer the name is, the harder it is to see it as a single unit while reading. Also, if the long names cause many extra lines, it becomes easier to lose context from the extra distance one moves down the document while reading.
Re: Want cleaner code? Use the rule of six
#255I don't necessarily agree with the step of putting the code in a separate function; that often works, but just as often makes it so that the code can't be read top-to-bottom anymore which hurts readability. In this case there's, I think, a better alternative; the equivalent-ish code in Ruby for the example code here would be something like this: values = s .partition('?')[-1] .split('&') .map { |key_value| key_value.…
Ruby maps are so ugly. .map { |key_value| key_value.partition('=')[-1] } Reading this literally makes me sick to my stomach. Language design is much more important than language popularity, although it will be popularity that wins. (Yay downvotes for pointing out things everyone can see - highschool dynamics)
I'm curious , can you show an example of how to achieve the same in another language that you will consider pretty?
Re: Want cleaner code? Use the rule of six
#256use statically typed programming languages. Favor composition over inheritance . Develop bottom-up (reusable classes) instead of large-scale up-front design. SOLID principles (SRP being the most important). The Bottom-up approach also favors Unittesting. Code reviews, clear code formatting rules (simple editor plugins do the trick). Use static code analyzers. IMHO this kind of object-oriented programming leads to NEW…
First point is killer. There's little reason for dynamic languages nowadays outside of scientific computing (e.g. Jupyter notebooks). A decade ago static typing did incur a real overhead in verbosity, but with popular languages adopting type inference algorithms there's no excuse anymore IMHO. Static types have won.
Re: Want cleaner code? Use the rule of six
#257Earlier quoted context omitted.
If you are unit testing you should not have to worry about tweaking a function and it breaking everywhere else.
> If you are unit testing you should not have to worry about tweaking a function and it breaking everywhere else. "should" is a word loaded with authority. Why? If you believe a unit tests is for turning an impure function into a pure function (so you can just test what it's doing and no other effects), then in many cases tweaking will break existing unit tests. If the function exists, it's assumed it's used by more…
> breaks the known contracts with other units.
which either forces you to fix those contracts - implying you have to go understand those contracts too. Or, you un-abstractify the function by keeping the original, and add a copy with the modifications you needed for the new feature/fix. This keeps the original contracts intact, but you add "bloat" to code - a form of tech-debt.
Re: Want cleaner code? Use the rule of six
#258Earlier quoted context omitted.
I've seen this complaint before and it doesn't really align with my experience of frequently seeing literal duplication of code where no extra abstraction was required to avoid it - just selecting the code in question and factoring it out into a function, which, providing you named it sensibly, would also make the code easier to understand and debug. I could count on one hand the number of times I've seen code where…
The point isn't to maintain the repeated code forever. The point is to generate the repeated code and (maybe) live with it for a bit until you understand what the right abstraction is and then remove the duplication with the correct abstraction. I've lost track of the number of times that I've taken badly abstracted code, reintroduced all the duplication, then refactored to remove the duplication with an entirely dif…
I've definitely seen cases where existing code was reused for a secondary, seemingly similar feature, unnecessarily complicating it and creating maintenance headaches when business requirements between the two features later diverged, and at best you might be able to claim it would have been better to simply copy & paste the code and modify it first, then look at how to refactor to avoid obvious cases of duplication. But I wouldn't consider that an example of developers trying to stay DRY at all costs.
Honestly the biggest problem I've had with maintaining the principle of not duplicating code is when a PO and/or UI/UX designer think we should only apply improvements to one feature to reduce the amount of work, when in fact it should be less work to apply them to all.
Re: Want cleaner code? Use the rule of six
#259In this case `query_params` works well, but it's sometimes hard to find descriptive and reasonably concise names for the intermediate value. In those cases, the ideal would be using only postfix chaining, so that you can read it by only keeping the intermediate value and the next operation in mind: s.split('?')[1] .split('&')[-3:] .map(lambda x: x.split('=')[1]) Unfortunately, that's not how Pythons map(), len() and…
Idiomatic Python wouldn't use a map here, but a generator expression: (x.split('=')[1] for x in s.split('?')[1].split('&')[-3:]) Removing the lambda cuts down on the noise considerably. And honestly, with this many splits with fixed indexes, I'd probably use a regex. Now there's a dense language for you.
i don't really see why or how a generator expression is any easier to read than a chained call like the OP's example.
In fact, for people unfamiliar with python, this expression is even more strange - you read expression starting from the middle (the _in_ ... part), and then return to the beginning. It makes your eye dart forward and backwards on the text.
Re: Want cleaner code? Use the rule of six
#260I don't necessarily agree with the step of putting the code in a separate function; that often works, but just as often makes it so that the code can't be read top-to-bottom anymore which hurts readability. In this case there's, I think, a better alternative; the equivalent-ish code in Ruby for the example code here would be something like this: values = s .partition('?')[-1] .split('&') .map { |key_value| key_value.…
Sub routines are underused. Make it a function right where it is?