Writing good code: how to reduce the cognitive load of your code

Post by AstralStorm » Wed, Mar 08, 2017, 6:12 AM UTC

TallGuyShort wrote: post #23

ser0 wrote: post #18

Sometimes I find myself writing in reviews for less experienced developers the comment: this is clever but not clear. I think as developers we get too enthralled in the problem solving and forget that in the long run we are more like journalists noting business rules at a snap-shot in time, which a future maintainer of our software must act as historian/archaeologist in order to understand. What's funny is that often…

One of the most valuable things I got from university was my professor's saying, "When somebody tells you your code is clever or interesting, that's an insult."

Post by lacampbell » Wed, Mar 08, 2017, 6:19 AM UTC

ser0 wrote: post #18

Sometimes I find myself writing in reviews for less experienced developers the comment: this is clever but not clear. I think as developers we get too enthralled in the problem solving and forget that in the long run we are more like journalists noting business rules at a snap-shot in time, which a future maintainer of our software must act as historian/archaeologist in order to understand. What's funny is that often…

Post by golergka » Wed, Mar 08, 2017, 6:40 AM UTC

julian_t wrote: post #72

golergka wrote: post #57

Earlier quoted context omitted.

But on what object? The fact that calling .MoveTo(10, 30) would return the same object it has been called on, and not, for example, a handle to created movement animation, is not exactly obvious. Modern pattern of methods which just return the objects that they've been called on, by default seems to be very trendy, but I fail to see how is it helpful.

Er... on the window, as the indentation and API tells you. It may be "not exactly obvious" to you, but having been doing GUI programming for a long time, this makes complete sense to me. It is also, of course, a matter of personal style and preference. (Aside: some friends tell me, a vi user, that the way Emacs works is obvious. I disagree, but then, I don't use it). And as for "modern"... I've been using this since…

Post by mfontani » Wed, Mar 08, 2017, 7:02 AM UTC

Singletoned wrote: post #114

brobinson wrote: post #105

Earlier quoted context omitted.

Ruby version is a pretty clear one-liner: validated_items = items.select { |item| is_validated?(item) } Though I'd expect a check for validation to be an instance method, so it'd probably look like: validated_items = items.select(&:validated?)

I don't find either of the Ruby versions clear at all. Both contain unnecessary syntax. Ruby seems to be going down the same path as Perl in trying to make all possible combinations of characters valid programs.

    my @validated = grep { is_validated($_) } @items;

Post by crpatino » Wed, Mar 08, 2017, 7:17 AM UTC

psyc wrote: post #89

onion2k wrote: post #39

Earlier quoted context omitted.

I can't articulate exactly why, but that should totally be flipped. Should it? If you accidentally use an assignment operator (eg = ) instead of a comparison (eg === )[1] with the constant on the left your code will throw an exception, which is what you want. If you put the variable on the left and accidentally use an assignment then you'll overwrite the variable with the constant value and return true, consequently…

This 'reason' is as old as C, and it's always seemed to me like tying bells to your shoelaces because it would be bad if you forgot to tie them and tripped. I.e. the 'solution' is orthogonal to the problem. If you can train yourself to put the constant first, you can train yourself to use the right operator. And you can test your code.