re: 10 CODING MISTAKES THAT MAKE YOUR CODE SMELL VIEW POST

FULL DISCUSSION
 

Can agree with these. Sometimes they can't be avoided.

 

True, but try to think on how to reduce them.

 

I would say this. In simple applications, following something like what Uncle Bob adheres to, it is easy to do what you suggest. However, some code is just complicated. Ideally, maybe 80-90% of code follows what you suggest, but sometimes it is too much to expect a developer to break everything up into functional units. It can be done but perhaps it isn't worth spending another week on an application that has taken three weeks.

Right now, I am building a publisher application and everything has been broken into simple objects with one method and using dependency injection but do I care enough to make the fact that it will only call four main functions follow the open closed principle;
NewReportPublication
SaveReports
PublishReports
NotifyEndPoint

Or can I get by with an enum and switch?

Anyway, open for discussion and good post.

Theoretically, it is easy, practically, it needs a lot of practice and logic.

Planning is important. I believe that spending 2 or 3 days brainstorming and planning will save you much time later on.

Goodluck with your project, once done, share a link so that I can check it :)

You're a developer and you know that time is crucial.

Have you ever worked on a project where the previous developer had a smelly code? Like bad names, comments....

I don't know. I don't like to pretend my sh!t doesn't stink. We all make mistakes when working and time pressure.

What appears readable and perfect to one person is not to another. Some patterns seem like nonsense to me, whereas others love it. I don't know if you are a C# developer, but as an example - should Entity Framework's linq expressions get exposed to the Business Layer? Or should it be abstracted away? I avoid using Entity Framework unless for clients but the answer is, of course - we should put a layer in-between. Many though would see this as overkill.

Anyway, you aren't talking to a new developer who struggles with these things, just I think we need to be a bit more balanced. But again, thanks for your article and it is useful for many.

I guess there's a misundertanding here.
The point in my question was: always think that there's another one that will read your code (it might be yourself after a couple of days, months or years).

No matter how experienced we are, we still make some mistakes, that's for sure. That's why we keep learning ;)

Thanks and glad you like my article Zak

code of conduct - report abuse