4 ms·

Have you considered that your "objective" analysis of what is "better" may still be very subjective, or just plain worse in some cases? A large number of short

Have you considered that your "objective" analysis of what is "better" may still be very subjective, or just plain worse in some cases? A large number of shorter functions, for example, can often be much harder to work with than one larger function that performs the equivalent processing. To properly understand such code (especially when it was written by somebody else), one must jump around from function to function, rather than just reading through one function from the top to the bottom. Likewise, "less interdependency between classes" often translates to more complexity in other places. To get usable software, the classes will still need to be connected together somehow. Sometimes this is done via automatic dependency injection, which usually brings in a whole new set of problems. Reuse is another "best practice" that often turns out to be bad in practice. It only works in those cases where the functionality being reused is truly general. Forced reuse of other, less-general code will often be problematic. The reused code soon starts needing to take into account slight variations in order to be used in several different places, and over time this builds up. This can ruin the code, resulting in a situation worse than had a bit of duplication been accepted. Crashing code isn't necessarily a problem, either. Taking a fail-fast approach is often a good way to detect unforeseen problems while developing code, before it gets into production use. Even once in production, it's better to have software crash in an obvious and reproducible way, so it can be more easily and rapidly fixed. It's often best for it to stop working completely, than it is to continue on and perhaps cause many more problems (such as data corruption, or a huge amount of network traffic, and so forth). It can be much worse to deal with code that "doesn't crash", but only because the original programmers caught and silently discarded any exceptions that were thrown, or error conditions that were raised. What you see as "good code" may, in a given context, actually be quite problematic. Perhaps your co-worker realizes this, and this is the cause for some of the friction you're experiencing.

caw 14y ago
> A large number of shorter functions, for example, can often be much harder to work with than one larger function that performs the equivalent processing. To properly understand such code (especially when it was written by somebody else), one must jump around from function to function, rather than just reading through one function from the top to the bottom. I wonder if there's an IDE that can do this -- substitute function calls with the actual function on demand. That might make both camps happy. It's readable in 1 sitting, but also DRY'd out.
- ZoFreX 14y ago
  There's a plugin available for Visual Studio that does something like that: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-4adf-bfef-83bd428a0acb http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-...
pi18n 14y ago
This is exactly what I thought would be irksome, and it was :) I am aware that it is hard to avoid a subjective analysis when it involves oneself, yes. So I'll just say, as far as your points on long functions, interdependency, and reuse, I agree, to a point. I'm not exactly writing, say, single line functions, though. As far as crashing goes, I throw exceptions over corrupting data, please give me some credit. I mean crashing as in some internal state goes awry (e.g., failing to lock properly in multithreaded code) so he doesn't know why it is crashing. I will take your comments under consideration. I'm afraid there's nothing I can do here that will prove I know what I am talking about, so I guess you will have to draw your conclusion on our dialog alone.

caw 14y ago

> A large number of shorter functions, for example, can often be much harder to work with than one larger function that performs the equivalent processing. To properly understand such code (especially when it was written by somebody else), one must jump around from function to function, rather than just reading through one function from the top to the bottom. I wonder if there's an IDE that can do this -- substitute function calls with the actual function on demand. That might make both camps happy. It's readable in 1 sitting, but also DRY'd out.

ZoFreX 14y ago
There's a plugin available for Visual Studio that does something like that: http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-4adf-bfef-83bd428a0acb http://visualstudiogallery.msdn.microsoft.com/4a979842-b9aa-...

pi18n 14y ago

This is exactly what I thought would be irksome, and it was :) I am aware that it is hard to avoid a subjective analysis when it involves oneself, yes. So I'll just say, as far as your points on long functions, interdependency, and reuse, I agree, to a point. I'm not exactly writing, say, single line functions, though. As far as crashing goes, I throw exceptions over corrupting data, please give me some credit. I mean crashing as in some internal state goes awry (e.g., failing to lock properly in multithreaded code) so he doesn't know why it is crashing. I will take your comments under consideration. I'm afraid there's nothing I can do here that will prove I know what I am talking about, so I guess you will have to draw your conclusion on our dialog alone.