20 ms·
No, that is not the restaurant industry version or the construction industry version. You can't possibly compare "good practices" in software with building code
by Zababa 5y ago
No, that is not the restaurant industry version or the construction industry version. You can't possibly compare "good practices" in software with building codes and food safety regulations. Building codes and food safety regulations are based on facts, science, and decades of experiences. Good practices are rooted in ideology, hype, and not based on facts. There are no studies showing that "having tests helps". There are no studies showing that "splitting code into multiple files means that you'll have a better end product". And experienced people (like in this thread) even say that there is often not that much correlation between how code "looks" and how well it works.
- 29athrowaway 5y ago> Good practices are rooted in ideology, hype, and not based on facts. That is a really sad statement that is predicated on the assumption that nothing can be objectively compared and therefore nothing can be ranked, which is also a way to kill arguments that lead to innovation and iterative improvement. You can measure the complexity of an algorithm, you can measure the cyclomatic complexity of a function, you can measure code in terms of length, you can count references to external functions or modules, etc. There are many ways in which you can compare code and make decisions about what style is more convenient for your team. What is clearer for you to understand? a) 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 + 1 b) 12 If your argument was true, they would both be the same. We both know that a) is a waste of time.
- Zababa 5y agoYour example is oversimplifying the problem, I don't think you're proving anything here. I've used tools that calculate cyclomatic complexity, and sometimes they're a good indicator, and sometimes they aren't at all. You can measure the complexity of an algorithm, sure, but unless it comes with a real life benchmark, it's only part of the answer. Same with the length of the code, you can measure the length but it doesn't tell you much about how hard to follow is the code. If you take any style guide, book about good practice, or stuff like that, you'll find that there are some good ideas, and there are some bad ideas. Even with something as simple as code formatting, we still don't know as an industry if it's better to format everything the same, or use formatting to convey information. The debates about OO, FP, static/dynamic typing are endless and there's no evidence about which is better. There is a rough idea that you need more organization when more people work on code (static types, microservices, more documentation, more isolated parts), but even that isn't really clear. My assumption is not that "nothing can be objectively compared and therefore nothing can be ranked". It's not even an assumption, it's what I've seen in this industry: we lack data to give objective good practice that go beyond anything trivial ("try to make code easy to read and simple", "give meaningful names to your variables"). There is a wide gap between "common sense" and "cargo cults", which is the gap between easy and complex topics. I would really like if in the last 50 years we had learn a lot about how to build software as an industry, as people. The reality is that we haven't.
- 29athrowaway 5y agoWe cannot objectively determine what is a good sandwich length therefore we should eat 1000 mile sandwiches.