This year I'm going to work very hard to eradicate the use of "clean code" from programming parlance.
-
-
-
Replying to @PaniczGodek
Because it's a highly-subjective term which is backed up by superstition. Instead, I'm going to reasoned code, backed by immutable laws.
1 reply 0 retweets 3 likes -
Replying to @hmemcpy
What I appreciate about the "clean code" movement is that it underlines the importance of code quality. I've worked at a couple of companies where everyone wrote their code however they liked. It is important to foster a particular culture of solving problems in a company IMO
1 reply 0 retweets 0 likes -
Replying to @PaniczGodek
You're right, it's a very important milestone. I noticed that some people (who are really good developers) think there's nothing beyond that. And sometimes "clean code" doesn't scale. I saw well-tested, well covered code that had classes taking 18 constructor arguments. "SOLID".
1 reply 0 retweets 2 likes -
Replying to @hmemcpy @PaniczGodek
The point is, it takes strict discipline, adherence to routine and rituals, in order to keep the code "clean". Other paradigms prevent that at various levels, e.g. Haskell restricts you from doing whatever you want, so the only way you can do something is the right way.
1 reply 0 retweets 1 like -
Replying to @hmemcpy
I used to think that about Haskell, until I started reading some Haskell code that didn't come from academic papers. Reading lines like ```let end = flip evalRandom rnd $ mapM (iterateM iters randStep) start``` didn't give any impression that this is "the right way".
1 reply 0 retweets 1 like -
Replying to @PaniczGodek @hmemcpy
I agree that functional programming makes it easier to prove equivalence of various programs. But type signatures are not a replacement for good names. As
@richhickey put it, foo:: [a] -> [a] tells you nothing, and reverse:: [a] -> [a] tells you everything.3 replies 0 retweets 0 likes -
Replying to @PaniczGodek @hmemcpy
[a] -> [a] is still weak. You want to say: reverse takes an ordered collection and returns *its contents* (even heterogeneous!) in the opposite order. "returns a's when given a's" would thus be implied. Type systems let you say what they can deal with, not what you need to say.
1 reply 0 retweets 3 likes -
Replying to @richhickey @PaniczGodek
But (honest question) how can this be enforced? I can *write* that 'reverse' means that, but how do I enforce it? I want the compiler/type system to help me here, not to trust the implementation is correct.
3 replies 0 retweets 0 likes
Static enforcement is not the programmer's problem. The problem is the customer wants their collections correctly reversed. 'enforcement' of [a] -> [a] is not much help. If we instead had more expressive specs then we could use both static and generative testing tools with them.
-
-
Replying to @richhickey @hmemcpy
Enforcement of [a] -> [a] allows that everything is plugged correctly, not that the right things were plugged. Of course, knowing that things were plugged correctly is a valuable information, especially if there is a lot of things, but this information shouldn't be overestimated.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.