DRY Code and what I mean by "Clean, Clear, Concise"

I'm not exactly sure where the three C's came from. Either I made it up or I heard it somewhere and it got stuck in my head. In my course, my instructor said something about keeping your code clean so I got a tiny bit obsessed with "writing the best possible code!!!".

So now my code is perfectly DRY, clean, clear, and concise! That's all. Just wanted to come here and brag. See ya later!

I scoffed at myself even writing that. We all know the truth. I don't follow these 100% of the time. Sometimes you just need to get that code out there. That was a few(a lot) of my homework assignments. Sometimes you're so caught up in what you're doing that you're not thinking about how you're doing it or you just don't know any better.

Now I am trying to make sure I do these things as much as possible and, even better, I urge my students to do the same right from the get go.

Ok but what does it all mean?

If you haven't ever come across the DRY acronym, those paragraphs must have been super frustrating. Let's break it all down together:

• DRY - Don't repeat yourself.
• Clean - Do not leave commented out code and console logs in your deployment!
• Clear - Organize, properly comment, and assign variables, classes, etc. that make sense.
• Concise - Don't put unnecessary junk in your code.

Don't Repeat Yourself

It doesn't matter to my students right now because our assignments are little saplings but we are going to need to be able to understand the concept. Since I'm writing these articles for all our new baby developers, I'll give examples that you can probably relate to:

• Utilize classes! To clarify, if you have multiple elements that are going to be styled exactly(or mostly) the same, give them a class name and squish that CSS rule together. It's ok. The elements know how to share.
• Put some selectors together. Are you going to have a couple of the same properties for multiple different elements, classes, etc.? Separate your selectors with comas and they can all share one rule.
• Use common logic! You will, at some point, and then every day for the rest of your life, call a function that is the same in every way to another one except the data you're feeding it. The data can share. Even if it doesn't want to.

For my current group of students, this is about as far as our material has taken us so we'll stop there for now. The point is you're writing a ton of extra stuff which takes time, makes debugging more difficult, and can eventually impact performance.

Clean up your code

Whenever project time rolls around, one thing I always tell the students is "When I am grading your project, I expect no commented out code, no console logs, and proper indentation." Look that's not just from me. It's in the rubric. But I am a tough(though fair) grader. I believe in being honest with my students because if we are trying not to hurt their feelings or to not be tough on them because they're new to this, we're hindering their learning.

Well that got teachery super fast. I am trying to impart some of that hindsight 20/20 stuff so you don't get into the same habits I did. You need to be able to be proud of your work when others look at it and tidiness will impress.

Ok. I know some people disagree about the console logs. I'm not gonna harp on it. I just want to remind you about what you might be logging to the console. I recently got into an argument about data security(with internet people) and I'm still a little hot about it. I just don't think we should take any chances.

Clarity is key

If I picked up your project, would I be able(honestly) to figure out what is going on by myself? If the answer is no, your code is not clear. Organize and comment(properly comment) your code.

• Name IDs, classes, functions, variables etc. things that make sense. "Banana" does not make sense(unless it does).
• Don't use acronyms. They don't mean anything without context.

I remember spending a few hours looking up "comment code best practice" and such. What it boils down to is "As much as needed. As little as possible." Basically you're writing a map for yourself or other developers. Remember, other devs who will be working on/looking at your code likely know what you know. You don't have to explain everything. Especially if you're using proper naming conventions for your variables, classes, IDs, etc. Comment your code:

• When there's a big shift in what's going on
• If there's something that is not self documenting(if you did something funky with your code)
• Where you change to a different section in your CSS and at each media query(personal preference and I like to just put the size so it's quick to find)
• When you have a function that changes the content in a major way

There are, of course exceptions and additions to all of this, but this is a good starting point. And if you want to comment each function to make it easier to find, that's great. But do it with a couple words. Something quick that you can scan through to get to where your going.

Your code should also be organized in a way that flows/makes sense. There are some standard practices for where stuff goes. There's gobs about this out there. But outside of that it should read like a story. The path should be clear.

• Use semantic HTML
• Write your CSS top down.
• Organize your CSS rules.
• Write your functions from the one that kicks everything off to the one that finishes it up.
• Group global variables by what they are/do.
• And give yourself some space! You don't have to scrunch up your code line by line. Putting a new line between things so that it's easier to find things later is perfectly acceptable.

I could go on and yes there are always going to be exceptions, especially when you get into bigger projects, but start here.

Concise is nice

It's not just nice. It's necessary. One of the things we try to do as developers with our code is make it smaller, more efficient, easier to write/read/use. Sometimes we do something that's just a little bit different and we want to explain it in comments in case it trips someone up. That's cool and completely reasonable, but there is a line between verbosity and sparsity that we want to stand on. There's always room for improvement but start here:

• Don't comment every single line of code
• Don't break down obvious things for people
• Don't write full sentences

You need to keep things brief but comprehensive. Give someone as much possible information with as few words as possible. If you find that you have to write whole sentences to explain your code, you're probably looking at a refactor in the near future.

I hope someone gleans something out of this. Some of these things are of course my personal preferences and I tried to point those out, but a lot of it came from hours and days of reading and rereading article after article. A lot of it came from my instructors and mentors and peers. And by all means if you have other ways of doing things I'm always ready to learn new things.

As always, I'm here if you want to ask questions or have a chat. Now have fun and happy coding!