3 ms·

It's always twice as hard to read code as it is to write code. True. For that reason alone, clever code is usually unmaintainable. How does this follow logic

It's always twice as hard to read code as it is to write code. True. For that reason alone, clever code is usually unmaintainable. How does this follow logically from the first statement? And more importantly, what alternative do you suggest? Are you positing that for a given problem, there is always some alternative solution that is "less clever" and "more maintainable?" If you've never seen folding and unfolding before, code that makes heavy use of "map," "each," "select," and so on looks clever. But in reality, it is simpler and less bug-prone than fooling around with for loops and off-by-one errors. To my eye, for loops are clever and unmaintainable. Moving up the scale, what about recursive combinators? https://github.com/raganwald/homoiconic/blob/master/2008-11-23/recursive_combinators.md https://github.com/raganwald/homoiconic/blob/master/2008-11-... They look very clever. But then again, rolling your own recursion from scratch every time you need it makes the person reading your code do a lot of work to figure out what you're doing. Is it "clever" to separate the concerns of how to implement recursive algorithm from the code that does something recursively? Or is it clever to roll your own code every time? WHat about parser combinators? Clever or not? How about rolling your own interpreter for a DSL? That's an official pattern from the GoF book. Can I do that and write maintainable code? Anyhow, I'm saying the same thing over and over. What is "clever?" Making use of a language feature or algorithm or well-known practice that someone else hasn't seen before and is too lazy to learn? And what is the alternative? Greenspunning the same functionality in an under-specified, bug-prone one-off way?

rapind 16y ago
I'd say clever is defined by your audience. If you're writing something that others on your team would consider clever, then you're responsible for making sure they understand it. Even if that means losing whatever time you saved by writing something clever (the advantage is still creating a smarter team though). Responsible developers write a lot less clever code because it means they feel obliged to comment the crap out of it and find the time to go through it with other team members. Unfortunately there's a lot more clever code that only one person really gets. If you're too clever for your team, then quit slumming it and find a smarter team. You're going to be toxic to a team that isn't as clever as you are unless you assume the role of mentor and all of the responsibility that comes with it... and the required patience.
- raganwald 16y ago
  Your response assumes that clever code exists to save time writing programs, and that for any problem there are a wide range of equally good solutions possible from "takes a long time to write but is easily readable and maintainable" to "quick to write but impossible to read and maintain by those who don't have doctorates in functional programming idioms." I don't dispute the existence of code that is unnecessarily clever, but I suggest that sometimes what appears to be "clever" for a given audience is in actuality the local optimum. Attempting to optimize it for readability without further study will worsen the code in some way, such as conflating concerns that have been carefully separated or introducing dependencies.
  - rapind 16y ago
    I can agree with that. I'd add that if something seems clever you might want to make sure others on your team are aware of it too. At least that way you won't get blamed for being too clever, and more people will understand what's going on.
    - raganwald 16y ago
      // Here be gryphons and scabrous wyrms
  - stcredzero 16y ago
    I suggest that sometimes what appears to be "clever" for a given audience is in actuality the local optimum. Attempting to optimize it for readability without further study will worsen the code in some way, such as conflating concerns that have been carefully separated or introducing dependencies. If "clever" is often necessary to avoid things like conflating concerns or introducing dependencies, I think this points us in the direction we need to take in improving programming languages. (Off the top of my head, this applies to both Ruby and Smalltalk.) Though, I've also observed that bolt-ons to programming languages to address these issues are often a bit too "clever" themselves. (Example: The original implementation of Objects in Perl.)
    - 16y ago

rapind 16y ago

I'd say clever is defined by your audience. If you're writing something that others on your team would consider clever, then you're responsible for making sure they understand it. Even if that means losing whatever time you saved by writing something clever (the advantage is still creating a smarter team though). Responsible developers write a lot less clever code because it means they feel obliged to comment the crap out of it and find the time to go through it with other team members. Unfortunately there's a lot more clever code that only one person really gets. If you're too clever for your team, then quit slumming it and find a smarter team. You're going to be toxic to a team that isn't as clever as you are unless you assume the role of mentor and all of the responsibility that comes with it... and the required patience.

raganwald 16y ago
Your response assumes that clever code exists to save time writing programs, and that for any problem there are a wide range of equally good solutions possible from "takes a long time to write but is easily readable and maintainable" to "quick to write but impossible to read and maintain by those who don't have doctorates in functional programming idioms." I don't dispute the existence of code that is unnecessarily clever, but I suggest that sometimes what appears to be "clever" for a given audience is in actuality the local optimum. Attempting to optimize it for readability without further study will worsen the code in some way, such as conflating concerns that have been carefully separated or introducing dependencies.
- rapind 16y ago
  I can agree with that. I'd add that if something seems clever you might want to make sure others on your team are aware of it too. At least that way you won't get blamed for being too clever, and more people will understand what's going on.
  - raganwald 16y ago
    // Here be gryphons and scabrous wyrms
- stcredzero 16y ago
  I suggest that sometimes what appears to be "clever" for a given audience is in actuality the local optimum. Attempting to optimize it for readability without further study will worsen the code in some way, such as conflating concerns that have been carefully separated or introducing dependencies. If "clever" is often necessary to avoid things like conflating concerns or introducing dependencies, I think this points us in the direction we need to take in improving programming languages. (Off the top of my head, this applies to both Ruby and Smalltalk.) Though, I've also observed that bolt-ons to programming languages to address these issues are often a bit too "clever" themselves. (Example: The original implementation of Objects in Perl.)
  - 16y ago