6 ms·

I was raised on programming contests and it took me many years to realize that clever code doesn't equate good code. In the vast majority of cases readability i

I was raised on programming contests and it took me many years to realize that clever code doesn't equate good code. In the vast majority of cases readability is more important than cleverness, performance, abstraction, and adhering to imaginary rules. The best measure for the quality of the codebase is whether at a glance you can understand what's going on.

hprotagonist 6y ago
> The best measure for the quality of the codebase is whether at a glance you can understand what's going on. ... in 6 months when you’ve forgotten 80% of the context.
- dnautics 6y ago
  Elixir is pretty good at this. I've found it really easy to do a (useful) drive-by pr on someone's open source code, for example, so that's with almost no context whatsoever. Nobody writes code like the op though (I'm pretty sure it's satire)
  - imperfectcats 6y ago
    I think having a tool to standardise formatting is huge, and a lot of what makes Elixir code easy to read is mix format. That and the fact most of the community started out with similar ideas on good code, so there was less bikeshedding around formatting.
    - dnautics 6y ago
      Eh, I think there are more important things, like if you pass a variable to a remote function, it doesn't ever mutate underneath you when you try to use it later.
      - mercer 6y ago
        Agreed. I maintain a whole bunch of codebases, many of which are a few years old, and it's so much easier to dust of an Elixir project (pre-formatter) than, say, picking up on a Wordpress or Drupal project.
    - Fire-Dragon-DoL 6y ago
      I have to disagree on this point. Formatting could be beneficial, but it gets abused so fast that it becomes a problem. First thing, no one challenges the choices made by the formatter, which is a problem in the long term. The other thing is how far the formatter goes. Rubocop in ruby is a clear example of this, they went way too far with it and producing a readable rspec test is impossible without violating at least one of the rules. A few days ago, I ended up writing something along these lines: ``` def something err, obj1 = dependency1.call(someargs) return err, obj1 if err.nil? err, obj2 = dependency2.call(obj1) return err, obj2 if err.nil? err, obj3 = dependency3.call(obj2) return err, obj3 if err.nil? err, obj4 = dependency4.call(obj3) return err, obj4 if err.nil? err, obj5 = dependency5.call(obj4) return err, obj5 if err.nil? [nil, obj5] end ``` This is a pipeline, to a human being it looks simple because the "return line" after reading the first time and understanding it's an early exit in case of errors, it's identical in all 5 steps. Human brain just excludes those returns after having read the first one. Rubocop however claims that there is too much complexity going on here due to 5 if branches. That's a machine reading the code. If I have to rewrite the code according to rubocop standards, it ends up being a lot less readable and with a lot more indirection for no particular advantage. I find it funny, we use styleguides to ease human interactions with code, but we let the machine evaluating that. It's problematic, the machine doesn't see the code as us.
      - andrewem 6y ago
        Are your objections to Rubocop's dictates in tests only (or primarily) about the complexity rules? The complexity rules have always struck me as being of a whole different category thnan Rubocop's other rules. As you note, they're especially frustrating in tests. Edit: by "the complexity rules" I mean https://www.rubydoc.info/gems/rubocop/0.27.0/RuboCop/Cop/MethodComplexity https://www.rubydoc.info/gems/rubocop/0.27.0/RuboCop/Cop/Met..., rather than the ones about variable naming, line length, etc.
        Fire-Dragon-DoL 6y ago
        My problem with Rubocop is both in tests and in normal code. The rules about complexity hit both tests and production code, while the rules about tests obviously impact only that (experience limited to RSpec). A senior developer won't need Rubocop, it's a blocker rather than an improvement. In the rare occurrence where you have an undisciplined senior developer, it's worth exploring training or re-evaluating the standards in place. All in all, I keep thinking this is a problem of culture, if it's addressed there the value in Rubocop decreases drammatically. That being said, Elixir formatter is "ok-ish". I didn't have the same problem with it because it doesn't overstep the boundaries of styling. It did remove valuable structure of the code for the sake of formatting standardization, so again it's actually doing damage, but at least it doesn't force you to write code that is more cryptic to a human for the purpose of pleasing a machine.
  - deleted 6y ago
    [deleted]
- setr 6y ago
  6 months..! Give me a few days and I'll have forgetton anything I didn't touch at least 3 times :-)
darkerside 6y ago
You are right in the context of software built for ownership but a team, typically in a commercial context. In other cases, side projects with an emphasis on learning, coding for fun, practicing, or just doing something neat, the clever code can meet other subjective standards for "goodness". I'm sure most people don't care, but that doesn't make it less true.
- dilap 6y ago
  Yeah there's definitely a place for both. That said, the older I get, the more I appreciate obvious code...
  - darkerside 6y ago
    Me, too. But I'd posit that's because we've written enough of the clever shit that we don't need to learn, play, and experiment anymore, at least to earn a decent living.
dkarl 6y ago
> The best measure for the quality of the codebase is whether at a glance you can understand what's going on. This is _so_ relative to the background of the people doing the glancing. These days [1, 2, 3, 4].map(x => x + 12).filter(x => x % 2 == 0) is obvious at first glance. Twenty years ago most people would have begged you to rewrite it with for loops. Right now I am in a hell of trying to figure out if the Scala codebase I'm working on is terrible or if I am just not fluent enough yet with FP and cats and related libraries. There are some points of style I'm confident are poor choices, but when it comes to other aspects that seem horribly convoluted to me... I'm still not sure if the code is written for somebody with more experience in the style, or if it's a poorly executed example of the style.
- aprdm 6y ago
  I agree with you that is obvious at first glance now a days but I wouldn't want to see it written like that in Python at least... I would prefer to have small functions named after what it is accomplishing and then have 2 function calls.. something like list_of_grades = [1 , 2, 3 4] adjusted_list_of_grades = apply_end_of_semester_grade_adjustment(list_of_grades) odd_grades = remove_even_grades(adjusted_list_of_grades) Of course that this example is very silly but understanding why a transformation is happening when you're looking an old code base that you don't have the context is easier w/ a function and docstring that explains it than a map or filter (IMO)
  - dnautics 6y ago
    I think also we have learned why map/reduce or functional recursion is better than for loops - because the state of the system is explicitly contained; with a for loop you could literally mutate anything in scope, so the cognitive burden to understanding the process is potentially unbounded; with map, your state between iterations is nothing, and with reduce, it's strictly what you can stash in your accumulator. I was laughing at myself the other week because I was having so much trouble writing a for loop because I had gotten used to the explicitness of the functional iteration operatiors
    - deleted 6y ago
cutler 6y ago
I was raised on Perl golf by Tim Toady so I have to respectfully disagree.
timoth3y 6y ago
> The best measure for the quality of the codebase is whether at a glance you can understand what's going on. I agree with you in spirt, but I would change "you" to "a new teammate" in the above sentence.

hprotagonist 6y ago

> The best measure for the quality of the codebase is whether at a glance you can understand what's going on. ... in 6 months when you’ve forgotten 80% of the context.

dnautics 6y ago
Elixir is pretty good at this. I've found it really easy to do a (useful) drive-by pr on someone's open source code, for example, so that's with almost no context whatsoever. Nobody writes code like the op though (I'm pretty sure it's satire)
- imperfectcats 6y ago
  I think having a tool to standardise formatting is huge, and a lot of what makes Elixir code easy to read is mix format. That and the fact most of the community started out with similar ideas on good code, so there was less bikeshedding around formatting.
  - dnautics 6y ago
    Eh, I think there are more important things, like if you pass a variable to a remote function, it doesn't ever mutate underneath you when you try to use it later.
    - mercer 6y ago
      Agreed. I maintain a whole bunch of codebases, many of which are a few years old, and it's so much easier to dust of an Elixir project (pre-formatter) than, say, picking up on a Wordpress or Drupal project.
  - Fire-Dragon-DoL 6y ago
    I have to disagree on this point. Formatting could be beneficial, but it gets abused so fast that it becomes a problem. First thing, no one challenges the choices made by the formatter, which is a problem in the long term. The other thing is how far the formatter goes. Rubocop in ruby is a clear example of this, they went way too far with it and producing a readable rspec test is impossible without violating at least one of the rules. A few days ago, I ended up writing something along these lines: ``` def something err, obj1 = dependency1.call(someargs) return err, obj1 if err.nil? err, obj2 = dependency2.call(obj1) return err, obj2 if err.nil? err, obj3 = dependency3.call(obj2) return err, obj3 if err.nil? err, obj4 = dependency4.call(obj3) return err, obj4 if err.nil? err, obj5 = dependency5.call(obj4) return err, obj5 if err.nil? [nil, obj5] end ``` This is a pipeline, to a human being it looks simple because the "return line" after reading the first time and understanding it's an early exit in case of errors, it's identical in all 5 steps. Human brain just excludes those returns after having read the first one. Rubocop however claims that there is too much complexity going on here due to 5 if branches. That's a machine reading the code. If I have to rewrite the code according to rubocop standards, it ends up being a lot less readable and with a lot more indirection for no particular advantage. I find it funny, we use styleguides to ease human interactions with code, but we let the machine evaluating that. It's problematic, the machine doesn't see the code as us.
    - andrewem 6y ago
      Are your objections to Rubocop's dictates in tests only (or primarily) about the complexity rules? The complexity rules have always struck me as being of a whole different category thnan Rubocop's other rules. As you note, they're especially frustrating in tests. Edit: by "the complexity rules" I mean https://www.rubydoc.info/gems/rubocop/0.27.0/RuboCop/Cop/MethodComplexity https://www.rubydoc.info/gems/rubocop/0.27.0/RuboCop/Cop/Met..., rather than the ones about variable naming, line length, etc.
      - Fire-Dragon-DoL 6y ago
        My problem with Rubocop is both in tests and in normal code. The rules about complexity hit both tests and production code, while the rules about tests obviously impact only that (experience limited to RSpec). A senior developer won't need Rubocop, it's a blocker rather than an improvement. In the rare occurrence where you have an undisciplined senior developer, it's worth exploring training or re-evaluating the standards in place. All in all, I keep thinking this is a problem of culture, if it's addressed there the value in Rubocop decreases drammatically. That being said, Elixir formatter is "ok-ish". I didn't have the same problem with it because it doesn't overstep the boundaries of styling. It did remove valuable structure of the code for the sake of formatting standardization, so again it's actually doing damage, but at least it doesn't force you to write code that is more cryptic to a human for the purpose of pleasing a machine.
- deleted 6y ago
  [deleted]
setr 6y ago
6 months..! Give me a few days and I'll have forgetton anything I didn't touch at least 3 times :-)

darkerside 6y ago

You are right in the context of software built for ownership but a team, typically in a commercial context. In other cases, side projects with an emphasis on learning, coding for fun, practicing, or just doing something neat, the clever code can meet other subjective standards for "goodness". I'm sure most people don't care, but that doesn't make it less true.

dilap 6y ago
Yeah there's definitely a place for both. That said, the older I get, the more I appreciate obvious code...
- darkerside 6y ago
  Me, too. But I'd posit that's because we've written enough of the clever shit that we don't need to learn, play, and experiment anymore, at least to earn a decent living.

dkarl 6y ago

> The best measure for the quality of the codebase is whether at a glance you can understand what's going on. This is _so_ relative to the background of the people doing the glancing. These days [1, 2, 3, 4].map(x => x + 12).filter(x => x % 2 == 0) is obvious at first glance. Twenty years ago most people would have begged you to rewrite it with for loops. Right now I am in a hell of trying to figure out if the Scala codebase I'm working on is terrible or if I am just not fluent enough yet with FP and cats and related libraries. There are some points of style I'm confident are poor choices, but when it comes to other aspects that seem horribly convoluted to me... I'm still not sure if the code is written for somebody with more experience in the style, or if it's a poorly executed example of the style.

aprdm 6y ago
I agree with you that is obvious at first glance now a days but I wouldn't want to see it written like that in Python at least... I would prefer to have small functions named after what it is accomplishing and then have 2 function calls.. something like list_of_grades = [1 , 2, 3 4] adjusted_list_of_grades = apply_end_of_semester_grade_adjustment(list_of_grades) odd_grades = remove_even_grades(adjusted_list_of_grades) Of course that this example is very silly but understanding why a transformation is happening when you're looking an old code base that you don't have the context is easier w/ a function and docstring that explains it than a map or filter (IMO)
- dnautics 6y ago
  I think also we have learned why map/reduce or functional recursion is better than for loops - because the state of the system is explicitly contained; with a for loop you could literally mutate anything in scope, so the cognitive burden to understanding the process is potentially unbounded; with map, your state between iterations is nothing, and with reduce, it's strictly what you can stash in your accumulator. I was laughing at myself the other week because I was having so much trouble writing a for loop because I had gotten used to the explicitness of the functional iteration operatiors
  - deleted 6y ago

cutler 6y ago

I was raised on Perl golf by Tim Toady so I have to respectfully disagree.

timoth3y 6y ago

> The best measure for the quality of the codebase is whether at a glance you can understand what's going on. I agree with you in spirt, but I would change "you" to "a new teammate" in the above sentence.