the only known metric for code complexity is as number of lines grows complexity grows
Irony, right?
Want cleaner code? Use the rule of six
71–80 of 352 posts
Re: Want cleaner code? Use the rule of six
#72Earlier quoted context omitted.
Yes, and a source file littered with tiny helper functions that do very specific things and don't make any sense except in the precise context in which they get called, isn't necessarily more readable. Here, "query_params" means "extract the last three query parameters, raw (i.e. not unescaped and not broken into key-value pairs)." The transformation shown makes precisely nothing more readable or easy to understand.…
I wouldn't attack the example too much, it does seem a little contrived to make the point - the very thing I don't like about contriving examples! It is hard to know whether the principle is valuable with such a weird example. In this example there are lots of other ways it could have been done more meaningfully but, again, don't know if the example is real.
What doesn't generalize is that the example doesn't necessarily stand for a simple one-liner, but as an example it has to be trivial, of course.
But everything else generalizes. I took "splitting out the last 3 params" to mean "doing something very specific to the problem at hand" and extracting that isn't _always_ better.
Re: Want cleaner code? Use the rule of six
#73I 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.…
> the code can't be read top-to-bottom
The idea of the technique is to split out code at a different level of abstraction with a clear name communicating what it does, while hiding the details of the how, because you don't need to care about that detail at all to fully grok the code in the calling function.
Where this breaks down is when the code you're trying to split out is not at a different level of abstraction, and how it works is meaningful to the surrounding code in the calling function.
So I think the issue you are seeing isn't with the technique, it's with the technique being misapplied. I think this is likely the only difference between when it 'often works' and 'just as often doesn't' in the code you're working in :-)
Re: Want cleaner code? Use the rule of six
#74Ok, quick rules that focus on single lines. That's neat, but from experience most of the complexity comes from the structure more than just how the code is written, conventions about how to write a line of code won't fix corrupt indirections, misplaced coupling, lack of cohesion, undue repetitions, missing tests, etc. Clean code is not just a few rules about how to write a line. You can write nice lines that still do…
Ah yes. I remember when I read the Clean Code about 10 years ago and produced the "cleanest" code I had ever seen – only to have it destroyed by a senior dev during a code review because the task was relatively complex and my overall structure was garbage. One of the saddest days of my career. Probably the most helpful day of my career too.
Re: Want cleaner code? Use the rule of six
#75I enjoyed the article and agreed that working memory places a fundamental limit on the intelligibility of otherwise equivalent pieces of code. As a former psychologist with experience of memory research (though not quite this area), it might be useful to others if I add that: - The size of the short-term store is normally said to be 7 plus or minus 2 (the 'magic' number 7) - The Working Memory model has somewhat over…
Not high priority, but I'd love any references or names / key words I could look into it with.
I'm traditional wide comp sci by academic training, but spend my day job as a low-code enabler for non-programmers with varied backgrounds.
The working memory model explains and fits well with what I see them get and struggle with in day to day work, and I'd welcome references I could use to optimize my approach.
Re: Want cleaner code? Use the rule of six
#76This rewrite is more performant than the original:
query_params = s.split('?')[1].split('&')[-3:]
map(lambda x: x.split('=')[1], query_params)
Re: Want cleaner code? Use the rule of six
#77I have written a lot of Powershell in the last few years. I eschew the clever powershell ways of doing things if someone else may end up owning it (think: where-object, foreach-object) in favor of expressions that resemble other languages (foreach, for). If I'm writing it for myself, and only ever myself, I'll use the more clever powershell ways of doing things. Expressions like: 1..10 | % {$_} If you're coming from…
Some things are short and self explanatory though. `1..10` is just syntax sugar for a stream or list from 1-10 right?
1..10 is powershell range operator, and % is an alias for foreach-object.
Re: Want cleaner code? Use the rule of six
#78in the example given, I started with 10 things to keep in working memory. now that we've added a named function or a named variable, we have 11. I suggest it is at least as important to name things well (or add comments) as it is to break lines up.
You forgot a KEY property of a function: this is an abstraction. You don't (and in most cases shouldn't) care how this "black box" does what it does, you identify it by the name and move on. So a function collapses N things to understand to 1, not how you have described it.
Exactly. At each level of abstraction, you don’t care what the functions look inside. The name must be enough to understand what it does.
You can of course descend one level, but at that point the layer above is no important. Just that the function fills the contract, possibly calling. Still more functions, which at that level are black boxes…
Re: Want cleaner code? Use the rule of six
#79I always liked the quote "you need to be twice as smart to debug a code. If you write smart code, you, by definition, cannot debug it" (sorry I have no idea who said this). This is why I still code in C. No smartass bullshit, just plain old undefined behaviour and out of bounds access. Lovin it.
This is from Brian Kernighan (the 'K' in the "K&R C Book" and AWK), known as Kernighan's law:
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
Re: Want cleaner code? Use the rule of six
#80I 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.…
Any way to do that in Python? Basically an anonymous function across multiple lines, which can be collapsed in the IDE view?
Not exactly the same but in python you can use pipe to create pipelines