1

I really need some advice as I've recently come into a conflict over a difference of opinion on the SOLID principles and writing clean code. One of our, relatively new developers but senior, does not agree with me that it is not a good idea to inject the Database context directly in the controller and then have all the business logic there. I've tried to argue against this but to no avail. His opinion is that it will create too many classes and doesn't see the point. I asked him if he has read Bob Martin's clean code and he hasn't; I'm also pretty sure he doesn't know what the SOLID principles are. I also work with another dev who is utterly clueless about writing any sort of clean code; his idea of that is if the code is indented properly. Unfortunately, I was reading through some of his code that was in a controller and I came across something that just seemed anathema to writing good code:

if (DbContext.Queue.Any(x => (x.Name == selectedQueue.Name || 
   x.QueueAlias.Any(xa => xa.Alias == selectedQueue.Name)) && 
   x.Id != Id))

   return BadRequest("The queue name: " + selectedQueue.Name +
                              " is already in use as a name or 
   alias. Please select a unique queue name.");

I then asked if this could be moved into a method to which the more senior developer, who I mentioned earlier, said there was no need as the return statement explains it. None of them seemed to understand that from a readability perspective, it's not good. Am I wrong in thinking this? Still more worryingly was another senior dev, who I looked up to, stated that most places don't bother using SOLID. That seems a bit of a sweeping statement. Is this also correct?

I honestly feel like I need to leave as I’m not on the same page as the rest of the team. I’m trying to follow the SOLID principles as best I can but I’m also still learning and I understand there has to be a trade-off. My fellow devs don’t seem to follow any standards just the ones they’ve come up with over time, which means it hard to communicate on a similar level about writing code and structuring the application.

I apologise if this sounds like venting but I really need some advice because, to reiterate, I think I may need to leave as I fear I’m working in a cowboy coding environment and I’ll just come into further conflict and not really advance myself as a developer. I think what I’m mainly asking for advice on, “is how do I argue that this is bad design and we need to refactor and we need to start writing cleaner code”. Plus, I’ve talked to my manager about this, and he’s told me if I can convince him, he’ll ask the rest of the team to start implementing SOLID.

19
  • 1
    I've created a very successful software engineering career for myself over the last 20 or so years. I didn't know the SOLID principles for most of that time, so I'm living proof that you can make it work without knowing them. Jun 27 '19 at 3:30
  • 4
    @RobertHarvey you really understood the 4 deep parentheses immediately? And know that it's error free?
    – user949300
    Jun 27 '19 at 5:30
  • 2
    I'm skeptical of SOLID myself but think that splitting this onto a function is good, not cause of SOLID, but could add clarity, and likely help with DRY.
    – user949300
    Jun 27 '19 at 7:04
  • 2
    @user949300 I've seen horrible code written by people trying to over-adhere to DRY, resulting in absolutely insane and overcomplicated code. Some people understand principles and patterns as absolute rules, and don't know how to adapt them to specific use cases resulting in good code. If this is indeed idiomatic code in C#, then the developer is "at fault" if he isn't familiar with it.
    – Kayaman
    Jun 27 '19 at 8:45
  • 2
    Refactoring repetitive code isn't part of the SOLID principles. See, this is what I'm talking about. If I worked at a place for several years where we did things a certain way, and a new guy came in and told me I was doing it wrong because Uncle Bob sez so, I'd be very irritated. Jun 27 '19 at 14:50

Browse other questions tagged or ask your own question.