5 ms·

I am a staunch code minimalist. Less code is (almost?) always better. The best, fastest, cleanest code is the code that doesn't exist at all. Always aim to writ

I am a staunch code minimalist. Less code is (almost?) always better. The best, fastest, cleanest code is the code that doesn't exist at all. Always aim to write the least code. Less code is less maintenance, it's less to grok for the next person to read it.

sneak 6y ago
I used to have this approach, but when you start to take deps into account, it is often preferable to have a medium amount of code in your own codebase (that eliminates some bulky deps) to a small, fast, clean/easy to read in full codebase that depends on some large external libraries that bloat the overall size of "lines of code in use in this application". Now I am a dependency minimalist (as much as is practical, it's a continuous gradient trade-off and naturally YMMV) more than I am a pure code-written-here minimalist. I'll happily double my SLOC for most small apps if it means my app can be stdlib only.
- fredley 6y ago
  Yes, fully agree. The only thing worse than code you have written is code you haven't.
  - folkrav 6y ago
    To a point. Some things are complex enough that relying on a well tested and supported third-party makes way more sense than re-inventing the wheel.
    - colejohnson66 6y ago
      I think a great example of that is GUI toolkits. If your program is supposed to be cross platform, using something like Qt, GTK, wxWidgets, etc. is generally preferred to writing your own GUI code.
      - srgpqt 6y ago
        Those GUI toolkits only look and behave acceptably on linux, because every other linux app uses those toolkits. They look horrible and incredibly jarring on windows and mac. Can still be fine for opensource/hobby work, anything professional needs better integration with the individual platform native UI apis. Which is one of the reasons Electron became so popular — nobody has any expectations from a webapp UI, yet they still look better than Qt/GTK/wx on average...
        simion314 6y ago
        I would say that Qt, GTK, Swing are perfect for application for doing your job. I know it sucks when this applications will not use the native file manager (Qt uses it but GTK refused maybe still refuses to integrate ) but at the end of the day most applicatons are created for heavy work and the UX is more important then the border radius of a button. So my opinion is if you want an app that looks perfect in screenshots or your customers are liking the buttonsand complain if the corners are not round enough then you should use the native looking stuff, but if your customers do their job using this app and every minute lost because of bugs. missing feature or bad UX then the look of the toolkit is not the issue, focus on what the customer is doing , see where you can improve his work and you will have happy customers.
- Wowfunhappy 6y ago
  Shouldn’t you be counting the lines of code in the dependency?
  - tyingq 6y ago
    I imagine the trouble there is that you often pull in a library for some smallish, but suitable subset of what it can do.
  - colejohnson66 6y ago
    A big problem with that is: what counts as a dependency? If I pull in Qt, am I supposed to add how many lines of code are in the parts I’m using? Many would say yes. But does using the Win32 API count? glibc? Where is the line drawn?
    - toast0 6y ago
      Every piece of code you rely on is a dependency. You may not be able to count lines of win32 code, and its awfully hard to make a patch, but if it's broken and you depend on it, your product is broken. There's also a multiplier that should be attached though. Most products don't have developer time or skills to write their own OS, so there's value in using someone else's even if it's probably more code than a custom built one that only satisfies the needs of the product.
  - renewiltord 6y ago
    The real reason objective measures don't work is that this is a subjective thing. When you think about the good things about code (readability, maintainability, extensibility) they don't lend themselves to mechanical analysis. We can proxy a little but the core problem is that the function that spits out your metrics for those actually has a hidden parameter of the audience you are writing for and the purpose it is for. So when the audience is highly familiar with Linux (the kernel and platform) idioms, you could choose an exotic microkernel with far fewer SLOC and actually have true lower score. Of course that's pointlessly edge case, but the natural simple easier to understand version of that is just using a different utility library instead of the one currently used in the codebase. This one could be smaller by far and still be worse in truth.
- lstamour 6y ago
  Another way of looking at it is that your dependencies are still part of your code and to minimize those as well. It can’t easily be taken literally because who really wants to consider the Linux kernel and glibc as part of their everyday app dependencies unless writing code very close to the metal, but at the same time it can be a very useful perspective to have. Especially when you consider that you might (for security) need to code review all those dependencies as they change over time.
  - vidarh 6y ago
    A reasonable approximation, to me, is whether or not another developer should be expected to have at least a reasonable understanding of the API of that dependency. E.g. we don't generally count (g)libc because a C-programmer should be familiar with the C API. We don't count Linux syscalls for the same reason, generally. But we might want to keep in mind that many APIs have dark corners that few users of the API are aware of, and so we may make exceptions. But the more obscure the API, the more important it is to count the complexity of the dependency as well. Both because it increases the amount of code your team must learn to truly understand the system, and because if it is obscure it also reduces the chance that you can hire someone to compartmentalise the need for understanding that dependency as well.
computerex 6y ago
I agree with this, with the side note that simple code is better than clever code when working with a team of people for most things. Barring performance constraints, I'd choose the code that's easier to grok/simpler even if it's more LOC.
- fredley 6y ago
  Yes. Code is read many more times than it's written, so optimise for the common case.
dnautics 6y ago
I don't think this is always true. For example, if you are writing tests, the DRY rule of three doesn't apply. It's very okay to repeat code if it prevents a layer of indirection for the person who is reading the test.
- dang 6y ago
  I puzzled about that for years and concluded that tests are a completely different kind of system, best thought of as executable requirements or executable documentation. For tests, you don't want a well-factored graph of abstractions—you want a flat set of concrete examples, each independently understandable. Duplication helps with that, and since the tests are executable, the downsides of duplication don't bite as hard. A test suite with a lot of factored-out common bits makes the tests harder to understand. It's similar to the worked examples in a math textbook. If half a dozen similar examples factored out all the common bits (a la "now go do sub-example 3.3 and come back here", and so on), they would be harder to understand than repeating the similar steps each time. They would also start to use up the brain's capacity for abstraction, which is needed for understanding the math that the exercises illustrate. These are two different cognitive styles: the top-down abstract approach of definitions and proofs, and the bottom-up concrete approach of examples and specific data. The brain handles these differently and they complement one another nicely as long as you keep them distinct. Most of us secretly 'really' learn the abstractions via the examples. Something clicks in your head as you grok each example, which gives you a mental model for 'free', which then allows you to understand the abstract description as you read it. Good tests do something like this for complex software. Years ago when I used to consult for software teams, I would sometimes see test systems that had been abstracted into monstrosities that were as complicated as the production systems they were trying to test, and even harder to understand, because they weren't the focus of anybody's main attention. No one really cares about it, and customers don't depend on it working, so it becomes a twilight zone. Bugs in such test layers were hard to track down because no one was fresh on how they worked. Sometimes it would turn out that the production system wasn't even being tested—only the magic in the monster middle layer. An example would be factory code to initialize objects for testing, which gradually turns into a complex network of different sorts of factory routines, each of which contribute some bit and not others. Then one day there's a problem because object A needs something from both factory B and factory C, but other bits aren't compatible, so let's make a stub bit instead and pass that in... All of this builds up ad hoc into one of those AI-generated paintings that look sort of like reality but also like a nightmare or a bad trip. The solution in such cases was to gradually dissolve the middle layer by making the tests as 'naked' as possible, and the best technique we had for that was to shamelessly duplicate whatever data and even code we needed to into each concrete test. But the same technique would be disastrous in the production system.
jugg1es 6y ago
I think there is a big difference between the the amount of code versus the number of decisions a piece of code has to make. When I think of 'code minimalism', I think of it along the lines of reducing the number of decisions made, but that doesn't always track with the amount of code. Bugs are always going to increase as the number of decisions are increased.
- deleted 6y ago
  [deleted]
- jackson1442 6y ago
  Exactly. You can get to the goal of less lines rather easily but it results in absolutely disgusting code since you're doing things like creating overly complex lines with nested ternary expressions. Easy to read code with fewer decisions should be the goal of a code minimalist.
RMPR 6y ago
Mandatory https://github.com/kelseyhightower/nocode https://github.com/kelseyhightower/nocode

sneak 6y ago

I used to have this approach, but when you start to take deps into account, it is often preferable to have a medium amount of code in your own codebase (that eliminates some bulky deps) to a small, fast, clean/easy to read in full codebase that depends on some large external libraries that bloat the overall size of "lines of code in use in this application". Now I am a dependency minimalist (as much as is practical, it's a continuous gradient trade-off and naturally YMMV) more than I am a pure code-written-here minimalist. I'll happily double my SLOC for most small apps if it means my app can be stdlib only.

fredley 6y ago
Yes, fully agree. The only thing worse than code you have written is code you haven't.
- folkrav 6y ago
  To a point. Some things are complex enough that relying on a well tested and supported third-party makes way more sense than re-inventing the wheel.
  - colejohnson66 6y ago
    I think a great example of that is GUI toolkits. If your program is supposed to be cross platform, using something like Qt, GTK, wxWidgets, etc. is generally preferred to writing your own GUI code.
    - srgpqt 6y ago
      Those GUI toolkits only look and behave acceptably on linux, because every other linux app uses those toolkits. They look horrible and incredibly jarring on windows and mac. Can still be fine for opensource/hobby work, anything professional needs better integration with the individual platform native UI apis. Which is one of the reasons Electron became so popular — nobody has any expectations from a webapp UI, yet they still look better than Qt/GTK/wx on average...
      - simion314 6y ago
        I would say that Qt, GTK, Swing are perfect for application for doing your job. I know it sucks when this applications will not use the native file manager (Qt uses it but GTK refused maybe still refuses to integrate ) but at the end of the day most applicatons are created for heavy work and the UX is more important then the border radius of a button. So my opinion is if you want an app that looks perfect in screenshots or your customers are liking the buttonsand complain if the corners are not round enough then you should use the native looking stuff, but if your customers do their job using this app and every minute lost because of bugs. missing feature or bad UX then the look of the toolkit is not the issue, focus on what the customer is doing , see where you can improve his work and you will have happy customers.
Wowfunhappy 6y ago
Shouldn’t you be counting the lines of code in the dependency?
- tyingq 6y ago
  I imagine the trouble there is that you often pull in a library for some smallish, but suitable subset of what it can do.
- colejohnson66 6y ago
  A big problem with that is: what counts as a dependency? If I pull in Qt, am I supposed to add how many lines of code are in the parts I’m using? Many would say yes. But does using the Win32 API count? glibc? Where is the line drawn?
  - toast0 6y ago
    Every piece of code you rely on is a dependency. You may not be able to count lines of win32 code, and its awfully hard to make a patch, but if it's broken and you depend on it, your product is broken. There's also a multiplier that should be attached though. Most products don't have developer time or skills to write their own OS, so there's value in using someone else's even if it's probably more code than a custom built one that only satisfies the needs of the product.
- renewiltord 6y ago
  The real reason objective measures don't work is that this is a subjective thing. When you think about the good things about code (readability, maintainability, extensibility) they don't lend themselves to mechanical analysis. We can proxy a little but the core problem is that the function that spits out your metrics for those actually has a hidden parameter of the audience you are writing for and the purpose it is for. So when the audience is highly familiar with Linux (the kernel and platform) idioms, you could choose an exotic microkernel with far fewer SLOC and actually have true lower score. Of course that's pointlessly edge case, but the natural simple easier to understand version of that is just using a different utility library instead of the one currently used in the codebase. This one could be smaller by far and still be worse in truth.
lstamour 6y ago
Another way of looking at it is that your dependencies are still part of your code and to minimize those as well. It can’t easily be taken literally because who really wants to consider the Linux kernel and glibc as part of their everyday app dependencies unless writing code very close to the metal, but at the same time it can be a very useful perspective to have. Especially when you consider that you might (for security) need to code review all those dependencies as they change over time.
- vidarh 6y ago
  A reasonable approximation, to me, is whether or not another developer should be expected to have at least a reasonable understanding of the API of that dependency. E.g. we don't generally count (g)libc because a C-programmer should be familiar with the C API. We don't count Linux syscalls for the same reason, generally. But we might want to keep in mind that many APIs have dark corners that few users of the API are aware of, and so we may make exceptions. But the more obscure the API, the more important it is to count the complexity of the dependency as well. Both because it increases the amount of code your team must learn to truly understand the system, and because if it is obscure it also reduces the chance that you can hire someone to compartmentalise the need for understanding that dependency as well.

computerex 6y ago

I agree with this, with the side note that simple code is better than clever code when working with a team of people for most things. Barring performance constraints, I'd choose the code that's easier to grok/simpler even if it's more LOC.

fredley 6y ago
Yes. Code is read many more times than it's written, so optimise for the common case.

dnautics 6y ago

I don't think this is always true. For example, if you are writing tests, the DRY rule of three doesn't apply. It's very okay to repeat code if it prevents a layer of indirection for the person who is reading the test.

dang 6y ago
I puzzled about that for years and concluded that tests are a completely different kind of system, best thought of as executable requirements or executable documentation. For tests, you don't want a well-factored graph of abstractions—you want a flat set of concrete examples, each independently understandable. Duplication helps with that, and since the tests are executable, the downsides of duplication don't bite as hard. A test suite with a lot of factored-out common bits makes the tests harder to understand. It's similar to the worked examples in a math textbook. If half a dozen similar examples factored out all the common bits (a la "now go do sub-example 3.3 and come back here", and so on), they would be harder to understand than repeating the similar steps each time. They would also start to use up the brain's capacity for abstraction, which is needed for understanding the math that the exercises illustrate. These are two different cognitive styles: the top-down abstract approach of definitions and proofs, and the bottom-up concrete approach of examples and specific data. The brain handles these differently and they complement one another nicely as long as you keep them distinct. Most of us secretly 'really' learn the abstractions via the examples. Something clicks in your head as you grok each example, which gives you a mental model for 'free', which then allows you to understand the abstract description as you read it. Good tests do something like this for complex software. Years ago when I used to consult for software teams, I would sometimes see test systems that had been abstracted into monstrosities that were as complicated as the production systems they were trying to test, and even harder to understand, because they weren't the focus of anybody's main attention. No one really cares about it, and customers don't depend on it working, so it becomes a twilight zone. Bugs in such test layers were hard to track down because no one was fresh on how they worked. Sometimes it would turn out that the production system wasn't even being tested—only the magic in the monster middle layer. An example would be factory code to initialize objects for testing, which gradually turns into a complex network of different sorts of factory routines, each of which contribute some bit and not others. Then one day there's a problem because object A needs something from both factory B and factory C, but other bits aren't compatible, so let's make a stub bit instead and pass that in... All of this builds up ad hoc into one of those AI-generated paintings that look sort of like reality but also like a nightmare or a bad trip. The solution in such cases was to gradually dissolve the middle layer by making the tests as 'naked' as possible, and the best technique we had for that was to shamelessly duplicate whatever data and even code we needed to into each concrete test. But the same technique would be disastrous in the production system.

jugg1es 6y ago

I think there is a big difference between the the amount of code versus the number of decisions a piece of code has to make. When I think of 'code minimalism', I think of it along the lines of reducing the number of decisions made, but that doesn't always track with the amount of code. Bugs are always going to increase as the number of decisions are increased.

deleted 6y ago
[deleted]
jackson1442 6y ago
Exactly. You can get to the goal of less lines rather easily but it results in absolutely disgusting code since you're doing things like creating overly complex lines with nested ternary expressions. Easy to read code with fewer decisions should be the goal of a code minimalist.

RMPR 6y ago

Mandatory https://github.com/kelseyhightower/nocode https://github.com/kelseyhightower/nocode