Still some of the best advice for programmers:
Don't be clever. Be obvious.
Along the same lines with driving:
Don't be nice. Be predictable.
@russsaidwords @fribbledom THANK. YOU. I can't tell you how much more satisfying it is to deal with someone on the road driving fast or aggressive, so long as they are both predictable and committed, than it is to be behind someone bloody dawdling along at 20-below the limit, too timid to make a turn, and who freaks out (and swerves into the on-coming traffic lane almost completely) when they happen to pass a car parked along the side of the road.
@fribbledom I spent a ton of time this week digging in the Git history for a string that was interpolated but could have been hardcoded. Not fun.
I never did find the code I was looking for.
@fribbledom "It pays to be obvious, especially if you have a reputation for subtlety."
@fribbledom i'm more from the "it was hard to write, it should be hard to understand" school of thought myself ;-)
There are rare cases when I write some clever code.
In those cases the comments are often as long as the code, or longer.
@fribbledom I went through a period of time when I fought myself on intermediate variables in calculations, but man it's nice to be able to step through (or even console.log) those results.
At this point I most often consider what the intermediates are and if it makes sense to inspect them and if they can be given a proper name. Sometimes I change operations around a bit just to get meaningful intermediates. I think it helps read, too. :)
return foo(x, y, bar(z, other_stuff))
Sometimes, if the symbol names are too long:
def some_func(x, y, z):
that's what I mean by "one or two lines." If it grows beyond that, context is lost and/or becomes harder to change with evolving business requirements.
def can_we_do_the_thing(policy, user, agent):
policy_status = api.isPolicySetUp(policy)
allow_override = user_is_cool && some && business && logic || other_case || yet_another_case
agency_status = agent.Agency.Status == 'yep'
return (policy_status && agency_status) || allow_override
@gws @tewha @fribbledom
Forth programming practice suggests that we should never deal with more than three items on the stack at any given time. This "rule of three" seems to be useful as well in non-Forth languages too. If you need 3 or more elements in a single expression, that's a smell that you might want to refactor that code.
@fribbledom And if you must be clever, comment your code.
@fribbledom I always feel like "clever" is one of the more damning things code can be described as.
@fribbledom Being clever — making the reader / listener solve riddles — often waste of brainpower.
@fribbledom this goes for ui design as well
@fribbledom "Keep it simple stupid"
@fribbledom those who want to be "clever" have not yet learnt that that does not demonstrate their skill.
Being obvious is far harder!
@fribbledom gonna ruin everyone's day by writing for(;stuff(););
1. write comments that describe your algorithm with pseudocode
2. implement EXACTLY what those comments say
3. stop programming. you are done. do not try to improve it.
@fribbledom that's actually good advice for anyone designing something to be used by other people. the more obvious and simple it is, the easier it is to pick up and use properly.
@fribbledom But you've got to be clever to be obvious, if "being obvious" isn't to mean "well of course I understand it".
@fribbledom how you gonna subtoot Perl like that
@fribbledom A thousand times yes!
@fribbledom Make your code obvious OR I WILL MURDER YOU
@fribbledom this is good advice for everyone.
@fribbledom If you must be clever, document the shite out of it, and be clear with the how and why of your cleverness.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!