Should you use a class? Should you use a Factory pattern or some other pattern? Should you reorganize your code? Whichever results in the least code is probably best.
A nice thing about code length is it’s objective. We can argue all day about which design pattern makes more sense, but we can agree on which of two implementations is shorter.
It takes a damn good abstraction to beat having shorter code.
But on a more serious note, I don’t really agree. Writing more code needs to be a conscious choice, but going for the shortest code too often creates a mess. I know, since I was that junior dev who just wanted to get stuff done and I would ignore project architecture in order to have to implement less, like accessing the database in GUI code.
Shorter code with the same amount of coupling between components and with the same readability is always better though.
but we can agree on which of two implementations is shorter.
Shortness for the sake of being short sounds like optimizing for the wrong metric. Code needs to be easy to read, but it’s more important that the code is easy to change and easy to test. Inline code and function calls are renowned to render code untestable, and introducing abstract classes and handles is a renowned technique to stub out dependencies.
i used to think like this. nowadays I prefer readability, and even debugability.
sure, I could inline that expression, but if I assign it to a constant with a descriptive name instead, the next person reading that piece of code will not hate me.
shorter code is not always better, especially when it comes to types. building in lots of guard rails by being verbose with the type system is a good thing. “shorter = better” is the python approach that starts off fun and easy but the codebase scales extremely poorly.
I think this is accurate on a larger scale, but I’ll often do things like breaking up a large chain of methods with an interim variable just for readability. A few lines of simple math is better than one line of bit shifting wizardry that does the same thing but doesn’t show the semantic meaning of the operation.
Shorter code is almost always better.
Should you use a class? Should you use a Factory pattern or some other pattern? Should you reorganize your code? Whichever results in the least code is probably best.
A nice thing about code length is it’s objective. We can argue all day about which design pattern makes more sense, but we can agree on which of two implementations is shorter.
It takes a damn good abstraction to beat having shorter code.
Here you go: https://codegolf.stackexchange.com/
But on a more serious note, I don’t really agree. Writing more code needs to be a conscious choice, but going for the shortest code too often creates a mess. I know, since I was that junior dev who just wanted to get stuff done and I would ignore project architecture in order to have to implement less, like accessing the database in GUI code.
Shorter code with the same amount of coupling between components and with the same readability is always better though.
That being said, if you access the database in GUI there is a high chance that you will repeat yourself making the whole program bigger.
Shortness for the sake of being short sounds like optimizing for the wrong metric. Code needs to be easy to read, but it’s more important that the code is easy to change and easy to test. Inline code and function calls are renowned to render code untestable, and introducing abstract classes and handles is a renowned technique to stub out dependencies.
i used to think like this. nowadays I prefer readability, and even debugability.
sure, I could inline that expression, but if I assign it to a constant with a descriptive name instead, the next person reading that piece of code will not hate me.
shorter code is not always better, especially when it comes to types. building in lots of guard rails by being verbose with the type system is a good thing. “shorter = better” is the python approach that starts off fun and easy but the codebase scales extremely poorly.
I think this is accurate on a larger scale, but I’ll often do things like breaking up a large chain of methods with an interim variable just for readability. A few lines of simple math is better than one line of bit shifting wizardry that does the same thing but doesn’t show the semantic meaning of the operation.
I agree. 100 lines of code may be 3x better than 300 lines of code, but 1 line of code isn’t 3x better than 3 lines of code.
I spent years writing an abstraction to be able to write shorter code… Not sure whether that was worth it 😅