8
15 Comments

Hey developers! What makes code bad?

Coming from a Project Management background! I would love to know what makes bad code, bad! Share your thoughts below!

Certain things, I'd like to look out for while Jemsplash.com and Jempost.com is in development.

Can't wait to read your thoughts devs!

  1. 7

    Here's a list. I'll reply in the comments if details or examples are needed (some of them might be controversial and subjective)

    • hardcode
    • code duplication
    • magic numbers
    • lack of comments
    • too many comments
    • outdated comments
    • deeply (>2) nested control structures (if, for, while etc)
    • obscure variable's names
    • very long functions
    • too many functions (highly subjective I know)
    • code duplication (see what I did there?)
    • hungarian notation
    • lack of formatting
    • non conventional formatting
    • premature optimization
    • copy paste when used indiscriminately
    • complicated logic for the sake of brevity
    • complicated logic for the sake of verbosity
    • dead code
    • lack of modularization
    • lack of abstraction
    • too much abstraction

    The list goes on but that's what I can think of right now.

    But none of this matter at all if you don't perform use input data validation and of course if the code doesn't do what it is supposed to, but I was assuming security and functionality are already covered just want to add a note here in case that's not obvious.

    A MUST read where many of these and many others are explained at length of the book "Refactoring: improving the design of existing code" by Martin Fowler.

  2. 7

    The number one thing? Rushing. Nobody does their best work in a firehouse. From a project management perspective: listen to their estimates (and give some buffer time) and don't constantly ask them how it's coming along.

    There are lots of ways to write "bad" code, but coding is somewhat of an art, and everyone has their own style. Rather than focusing on things that make code "bad" (usually it's not just one thing), I'd like to outline a few points that would make it GOOD:

    • Tests -- these can be unit tests, feature tests, integration tests, etc... automated testing is almost always a good sign. Not a requirement by any means, but it pays huge dividends as a codebase grows.

    • Thought process -- "keep it simple, stupid". This one is tough to measure, but might have the biggest impact on the resulting code. Simply put, it's how the developer thinks. Put another way it's "make the change easy, then make the easy change". Working in small, frequent iterations instead of massive "do everything" changes aligns well with this philosophy.

    • Modern standards -- varies dependent on tech stack, but following modern standards for things like HTML, CSS, JS and PHP are a big plus. Web development technologies move fast! Great developers are constantly learning new stuff. Not everyone needs to be on the "cutting edge" with the latest stuff, but at least being close is a good start.

  3. 3
    1. It doesn't do what it was meant to do.
    2. It's too slow.
    3. It's not flexible enough to change it without too much time / efforts.
    4. It's not understandable enough to maintain it without too much time / efforts.
  4. 2

    The algorithm of good code: divide complexity by efficiency and keep trying to reduce complexity while you increase efficiency. Bad code is the opposite.

  5. 2

    Three core principles I found quite useful

    1. KISS - "keep it simple stupid", simplicity is the best in UX, UI, and code. Forget complex abstractions, generic classes, multi-layer architecture unless they make your code simpler. Which most of them usually do. This brings the next important principle

    2. YAGNI - "You aren't gonna need it". If you don't need it right now don't code it. There were so many situations when I added some class, service, or even an entire feature that was not needed at all. Some of them still pollute my code.

    3. DRY - "Don’t repeat yourself" - one of the core principles, but should be used only and only during refactoring. You found duplicates, you eliminate them by abstraction, generic classes, etc.

    All of these principles perfectly implemented by Test Driven Development which I highly recommend adopting

  6. 2

    Bad code = what is hard for you to maintain.
    Readability is the most important part. You need to be able to understand your code half a year later.

    Follow the KISS (Keep it simple, stupid) and the DRY principles (Don't repeat yourself).
    Limit the number of external dependencies (the number of bundles, libraries you use in your code)

  7. 2

    From my experience on the thing will always lead to bad code. The neglect of code refactorings.

    As mentioned there are many reasons for that everything from stress and pressure up to missing experience. Having the motivation to make the code base every day just a tiny bit better will have a huge impact.

  8. 1

    What makes code bad is highly contextual (eg, good code in a school assignment might be bad code in a SaaS app), so I’ll focus comments on a single context: Code written in a team environment, intended to bring a business revenue.

    Code is bad when it’s hard to change.

    Why? Because software in this context is never finished—it’s either dead or evolving to meet business needs.

    If you can’t change something because the only person who knows about it quit or is on vacation, that’s bad code.

    If you can’t change it because it might break another part of the system in unpredictable and untestable ways, thats bad code.

    If you can’t change it because it’s too complicated for the team to read and understand, that’s bad code.

    On the other hand, good code can be modified quickly to suite business needs. It can be changed without jeopardizing functionality. And it can be maintained by a team of developers.

  9. 1

    There are so many ways to write bad code. Here are a few principals that I find are helpful when it comes to creating quality code:

    1. Code should be readable. Code is read many more times than it is written.
    2. Follow SOLID design principals (see Wikipedia for details)
    3. Keep coupling low and cohesion high when designing modules (again see Wikipedia for details).
    4. Write a good set of automated unit tests.
    5. Keep infrastructure concerns (databases, file systems, etc.) abstract so that unit testing is possible.
    6. Refactor your code. As Kent Beck said: "Make it work, make it right, make it fast".

    I wrote a blog discusses code quality. See "DEPENDENCY INVERSION AND THE CLEAN ARCHITECTURE" at T2pDev.com.

  10. 1

    There are many best practices, which definitely all have their place, but in my opinion the one which rules it all is to keep stuff as simple as possible.

    Ultimately you'd approach this top-down. First ensure your overall architecture is simple to work with. As soon as you have achieved this there is some leeway for chaos in individual subcomponents given it's easier to refactor these. Try to work it all the way down from the architecture to the individual statements. Flexibility in the future direction is more important than a 'correctly' designed system.

    ----

    Edit; Put in another way; ensure the project requires the least amount of cognitive load to maintain. Having to search for specific bits of functionality is an indicator you got something wrong, and need to spend some time reorganizing an project. Through experience I know it's possible to write complex code with the mental capacity of a 4 year old, but only if everything is simplified to the bare essentials.

    And oh, please, please, please let the code have similarities with the business context. I see it way too often that the terminology and code structure does not match at all with the business processes within an organization. This way a software developer needs to maintain two interconnected but separate contexts in their head. One which dictates the way the business intends to operate, and a shadow copy which contains all the details of the software. Ideally it should be possible to employ the same mental model for both contexts.

    At last, do not underestimate the effort it takes to write high quality code (easy to maintain; while doing the job well and stable). Personally I write only 5 executable lines of code per hour.

  11. 1

    Hey, so some key things I look out for:

    Simplicity - Sometimes developers feel the need to be 'smart' in their solutions. Imo the code should be as simple as possible so that the next developer doesn't have a learning curve to be able to understand it. To spot this from a non Dev point of view, ask them to explain it in non technical terms, every time they mention somthing you will have to Google, it's a warning sign (obviously dependent on your own knowledge)

    Write tests: tests are great at making the dev think about the code they're writing, the pain of having to write a test for a badly written function that has side-effects and is tightly coupled with other functions often leads them to rewriting the function into smaller pure functions. The also serve as a safety net in the future as breaking changes should be caught if the tests cover the logic correctly.

    To me they're the two most important points at making sure your team produces quality code.

  12. 1

    I think this could be addressed in multiple layers and such.
    First I would say writing bad code might at times be the good thing to do - if it's a one off use, total trash-able POC/MVP etc...

    Code such as with writing can be improved by putting more time into it, going and refactoring (rewriting) for example.

    What leads to code starting to smell over time in a major way is usually changes in concepts/design from the original version in feature side landscape while code is still using early conspectus and just being patched on top doing the minimal amount of work (hot-fixes, workarounds and hacks..) vs redoing code design, like matching the flow, objects and structures to match the feature world.

    On a more holistic view I'd say that the test of good vs bad code is that if you get an experience programmer on it, how much knowledge do you need to transfer for him to be useful. So anything in your head which isn't in code, docs etc is a hindrance as well as any concept specific to the code...

    There are different level of tools to help you get a feel on how bad the code is going from simple linters to complexity checkers of sorts. As mentioned automated tests are a way for you to add documentation in a way, regression/mine avoidance by unit tests, and further expectations by further automated testing and processes. But there is always going to be the logic layer which would be hard to score, but in a way as I mentioned, probably how much does the code much the feature set... one should probably make code design diagrams vs user feature diagrams to show how closely they match, if they are easily mappable in a 1:1 fashion, the logic layers is probably pretty good. Decoupling between sections is also an important part for this to be true.

  13. 1

    Focus on readability instead of saving 2 lines of code. You (and others) will be happy you do when you look at the code at a later time.

  14. 1

    Lets assume the fundamentals are all there (correctness, testing, etc). From a PM's perspective, any code that is difficult to maintain should be considered to be "bad code". This has three implications:

    1. A small code base (e.g. under 100 lines) that does one thing can be written excessively poorly, but could still be considered to be "good code". With a small enough codebase there is no difference between a refactor and a rewrite. So it makes sense to optimize for speed assuming correctness is there. There are opportunity costs for things, after all.
    2. Adding to new features to a codebase makes it worse and make it a step closer to being "bad code". When we build something we don't always make affordances to every possible feature. So when a new feature is added, it made a little less intuitive to maintain and there is literally more that needs to be maintained. This is technical debt!
    3. Removing features makes your code better! If there is less to maintain, it is easier to maintain.

    The implication here is that you need to be careful when growing a small codebase. For example, when you have an MVP (which was optimized for speed and validating an idea) and are constantly adding new features... that is an engine to create technical debt. Especially since the mandate for the MVP will evolve a lot as you acquire new learnings. Ideally, it would be best to throw away the MVP once you determined what the product should be doing, but realistically not a lot of companies have that luxury. The next best thing is to make time to prune failed experiments and not hoard features if they don't provide value.

  15. 1

    To address the technical aspect of code (I am taking just one of many interpretations of "bad code") I like this post:
    https://javascript.info/ninja-code
    ⚠️ Warning: irony detected lol

  16. 1

    This comment was deleted 3 years ago.

  17. 1

    This comment was deleted a year ago.

  18. 1

    This comment was deleted 4 years ago.

Trending on Indie Hackers
How I grew a side project to 100k Unique Visitors in 7 days with 0 audience 48 comments Competing with Product Hunt: a month later 33 comments Why do you hate marketing? 28 comments $15k revenues in <4 months as a solopreneur 14 comments Use Your Product 13 comments How I Launched FrontendEase 13 comments