5 ms·

DRY and SRP are the air I breathe, so I need to defend it. "This means that when reading through the original caller, it is less clear what the code does." Th

DRY and SRP are the air I breathe, so I need to defend it. "This means that when reading through the original caller, it is less clear what the code does." This is false - if you have a clear service and method name, with clear, properly-typed params, it SAVES time, because unless it's broken, it's a SHORT invocation that abstracts the details. "the function might have some surprising semantics. For example, mutating contents of local variables is sensible in code." Pure functions are the only "apply everywhere" part of the functional programming paradigm. Side effects are just as painful in .NET and Java as they are elsewhere. "Overgeneralized code" SRP let's you identify this fairly easily. As an example, I just tried to abstract away "Edit" and "SuggestEdits" in the same controller to stay DRY, but then realized it violates SRP. "Each modification of the "common" function now requires testing all of its callers. In some situations, this can be subtly non-trivial." Much less painful then knowing you have to change it in multiple places AND THEN checking the code. Just doesn't apply. "When each of those code segments were repeated, ownership and responsibility were trivial. Whoever owned the surrounding code also owned the repeated segment." The team owns the code. At worst, the lead owns the code. Bad excuse. Feels like a dramatic contrarian piece to me. As mentioned, SRP and DRY are the only two things that allow our team to keep churning without significant tech debt. That, and avoidance of magic strings. These 3 things are probably 80% of clean code. Edit: Oh, and keeping methods to 5 lines or less, except in genuinely extreme, rare cases. Of course that's theoretically under "SRP and abstraction", but you know.. Edit 2: The single source of truth comment is on point as well. There was a rule when Python was designed "There should be ONE, and ideally ONLY one way of doing things." This is extremely important to writing good code and on-boarding people onto your project.

dj_mc_merlin 6y ago
> Oh, and keeping methods to 5 lines or less, except in genuinely extreme, rare cases. This confuses me. Extreme, rare cases? Don't get me wrong, I code Lisp as much as anyone and love keeping my functions short and simple, but not going above 5 lines (esp. in Java or .NET) is masochistic. By that metric, an if in Java takes up 60% of a function's real-estate, a local variable 20%, and a try-catch is your maximum complexity.
- throw1234651234 6y ago
  I do think your example should be as simple as: try { _legacyCandidateRepo.SaveWithIncrementalBackoff(candidate); } catch (Exception exc) { HandleException(exc); } This way, the code is extremely readable, especially if you can easily "Go to definition" in a service, and the file this try-catch isn't 200 lines long. Also, try-catch is generally an anti-pattern. It should only occur when you genuinely have no way whatsoever to prevent the exception, as such, it will be pretty rare. Again, it does happen, for example we have an unstable legacy db we hit that we don't have access to, but it should be fixed asap. Tbh, this is a constant argument between our juniors and I. They want to write 15 line methods, but I have found that they don't want to debug it. It's constantly them building quickly on top of my code and then me having to fix theirs because they get frustrated debugging their own code.
  - dj_mc_merlin 6y ago
    Whatever is inside the catch block is by definition the exception handler, so I find the extra function definition to not bring much value. It also doesn't annoy me too much since I can just go to definition, but if it's only 3-4 lines long I would rather have it in the block itself so I can read it at a glance. > try-catch is generally an anti-pattern. Exceptions are a very useful part of the language if you use them right (to divert code flow in predictable ways in unpredictable scenarios), although I agree it can be easy to go wrong. Regarding your juniors, that seems more of a problem of skill or determination than anything. Debugging in Java is relaxing, it has stack traces, a debugger, a nice IDE, no segfaults.. a 15 line function should not be an obstacle. I would even prefer to have more of the code on the screen sometimes so I can get the implementation details in my head .

dj_mc_merlin 6y ago

> Oh, and keeping methods to 5 lines or less, except in genuinely extreme, rare cases. This confuses me. Extreme, rare cases? Don't get me wrong, I code Lisp as much as anyone and love keeping my functions short and simple, but not going above 5 lines (esp. in Java or .NET) is masochistic. By that metric, an if in Java takes up 60% of a function's real-estate, a local variable 20%, and a try-catch is your maximum complexity.

throw1234651234 6y ago
I do think your example should be as simple as: try { _legacyCandidateRepo.SaveWithIncrementalBackoff(candidate); } catch (Exception exc) { HandleException(exc); } This way, the code is extremely readable, especially if you can easily "Go to definition" in a service, and the file this try-catch isn't 200 lines long. Also, try-catch is generally an anti-pattern. It should only occur when you genuinely have no way whatsoever to prevent the exception, as such, it will be pretty rare. Again, it does happen, for example we have an unstable legacy db we hit that we don't have access to, but it should be fixed asap. Tbh, this is a constant argument between our juniors and I. They want to write 15 line methods, but I have found that they don't want to debug it. It's constantly them building quickly on top of my code and then me having to fix theirs because they get frustrated debugging their own code.
- dj_mc_merlin 6y ago
  Whatever is inside the catch block is by definition the exception handler, so I find the extra function definition to not bring much value. It also doesn't annoy me too much since I can just go to definition, but if it's only 3-4 lines long I would rather have it in the block itself so I can read it at a glance. > try-catch is generally an anti-pattern. Exceptions are a very useful part of the language if you use them right (to divert code flow in predictable ways in unpredictable scenarios), although I agree it can be easy to go wrong. Regarding your juniors, that seems more of a problem of skill or determination than anything. Debugging in Java is relaxing, it has stack traces, a debugger, a nice IDE, no segfaults.. a 15 line function should not be an obstacle. I would even prefer to have more of the code on the screen sometimes so I can get the implementation details in my head .