Quickly, to summarize my previous post, DRY code is code that doesn’t repeat itself – that eliminates redundancy by using best practices and modular functionality to group together and reuse code. DRY code is vital to applications and websites: it allows for quicker development time, it makes them easier to maintain – for developers and clients, and it helps them perform more reliably and faster.
HTML can be difficult to keep dry, especially if you’re not using some kind of fron tend framework. HTML is used to create the structure of a page, and given that it can be challenging to not be over-descriptive while creating a page.
One of the most crucial things to developing DRY HTML is solid naming conventions. Naming your HTML classes and ID’s on a whim can lead to <div> soup that confuses the overall structure and leads to excess code. Instead, consider your structure thoroughly, use the smallest number of elements that will still accomplish your goal, and then carefully choose descriptive classes and ID attributes that describe each element. Is that <div> wrapping another element? Sure, but don’t assign it an ID of “div-wrapper.” Instead, notice that it’s containing your page’s footer social items and call it “footer-social,” or something equally descriptive and unique.
In terms of naming conventions with classes and ID’s, also consider leaning towards the use of classes. Classes can be applied across multiple items – for example if you have multiple buttons on a page, they can all be grouped under a “buttons” class. The alternative is assigning an ID to each button on the page, and styling it uniquely – which bloats both your HTML and your CSS.
CSS can be very easy to keep DRY, but the temptation is always there to lose focus while trying to solve a particular problem and deviate from the things that naturally make CSS clean.
First remember what CSS means – Cascading Style Sheet. The browser that is interpreting your CSS is going to start at the top and move to the bottom, meaning rules towards the bottom have the potential to hold the most influence. Given that, ordering is obviously key. To keep my code DRY, I like to focus on one section of my page at a time and work my way down. This creates a natural flow (header styles should be at the top, and footer styles should be at the bottom of my CSS!), but more importantly it keeps me from jumping around the page and writing potentially conflicting CSS, and then duplicating, negating, or overwriting other code. Ordering your CSS well, in whatever style works for you, is key to keeping it DRY.
CSS also targets elements based on levels of specificity – ID’s holding the most weight, followed by classes, followed by general element tags themselves. That means you should always write your CSS using the least amount of necessary specificity required to achieve the desired effect. You can certainly target your div with an ID of “image-wrapper” and class “pull-right”, but if you need to write rules farther down your CSS (maybe a media query for your responsive layout?) you must use at least the same amount of specificity or more to make any updates. Using less specificity keeps things cleaner, and also causes less frustration towards the end of a project.
Also consider using SASS, or its alternate syntax, SCSS. I like to use SCSS which allows you to nest style rules within others. This allows you to visually see the structure of the page you’re styling better, as well as gives you visual hints when you’re being redundant.
This is obviously a high-level review of how to keep your front end code DRY. In the comments, let us know your other tips and tricks to make your clean code even better by applying the concept of Don’t Repeat Yourself.
One of the core principles of modern programming languages is the concept of never coding the same thing twice: Don’t Repeat Yourself (DRY). If you’ve looked over a stylesheet and noticed redundancies, used loops over and over and over when a more simple solution might be available, or found yourself writing suspiciously familiar HTML, then you know what DRY code isn’t. Simply put, DRY code takes the redundancy out of coding by grouping blocks of reusable code into methods, functions, rules, or templates that allow for simpler, more readable, and more powerful programming.
This has obvious benefits for coders. Keeping your code DRY improves organization, speeds up development time, makes debugging faster and easier; the works. As as a junior developer it’s really easy to forget this (learned from personal experience!), especially with the weight of deadlines closing in. That said, there’s almost nothing more valuable than writing DRY code the first time around, even if it takes longer. The alternative is scrambling to remember where that one line of code is with a looming deadline. Do the heavy lifting at the outset and even as pressure mounts you’ll have the confidence that you are not writing brittle code, coupled with the fact that you’ll be delivering a better end product.
DRY code also gives you powerful tools to use right away, right in the middle of writing an application. Sure, it helps avoid the more obvious pitfalls of writing bad code. The corollary, however, is that DRY code makes your program syntactically more readable. Imagine being handed a functional program, only to dig in and find out it was written as a stream-of-thought mess. It might work, but where will you begin if you need to make a simple update? DRY code up as you’re writing – your collaborators and successors will thank you. This standard is also a matter of working smarter and not harder. A complex function or method can often be summed up in a single word. Write 30 lines of code over and over to achieve the same result, or DRY it up by creating custom methods and calling them with one word or phrase? The answer is an easy one.
But why should you care if you’re a client, a manager, or anyone else, if code is written in a DRY fashion? Wait time. Reliability. Product lifetime. Programs that are written cleanly run faster than those that repeat themselves time and again. This means that your website or application avoids iterating over data, combing through stylesheets, or other time-consuming tasks that may be completely avoidable. Additionally, programs that you use on a daily basis need to be reliable. If that program is written well then you can be confident that their execution and the results you receive (be it a business report from company software or a Google search result) will be useful and accurate. Finally, code that isn’t maintained has a shelf-life. Standards change, browsers adjust over time, plugins adapt, and programs that don’t actively adapt with changes have the potential to become brittle. That said, code that is written with best practices in mind will last longer and will require far less maintenance. A product’s codebase must follow DRY standards to keep a brand healthy and in front of clients for the long haul.
Building DRY programs isn’t just a best practice, it’s an easy way to keep everyone—from programmers to business owners to end users—running smoothly on powerful applications.
Have you DRY’d out your code? Next time, we’ll take a look at specific methods to DRY your code. In the comments below, tell us about a time that DRY’ing out your code saved your project.
This is the first installment of a new series designed to introduce non-programmers to some foundational computer science concepts towards a better understanding of the development process. We decided to begin with MVC.
MVC is a pattern of software architecture/development that divides an application into three interrelated components: Model, View, and Controller. MVC is designed and implemented to improve maintainability and provide Separation of Concerns.
Originally applied to desktop applications, MVC has become an important architectural/design concept for web-based applications over the last decade or so with frameworks like Ruby on Rails, Django, and the ExpressJS+NodeJS+MongoDB stack.
The Model is responsible for managing the the data, logic, and rules of an application.
The controller accepts input and converts it to commands for the model or view.
A model stores data that is retrieved to the controller and displayed in the view. Whenever there is a change to the data it is updated by the controller.
A view requests information from the controller. The controller fetches it from the model and passes it to the view that the view uses to generate an output representation to the user.
A controller can send commands to the model to update the model’s state (e.g., editing a document). It can also send commands to its associated view to change the view’s presentation of the model (e.g., by scrolling through a document).
MVC and Web Apps
When considering which platform to recommend to a client, it can be useful to think about the core logic involved with the application. Applications with relatively light-weight logic and simple data-queries may be best suited for more View or client-heavy framework such as AngularJS or Backbone, whereas those with extensive logic and/or complex data-queries might be better candidates for a Model-heavy framework like Ruby on Rails. This is of course not the only thing to consider when choosing which framework is right for your client, but it can be a good starting point. Having members of your new business team, for example, understand the concept of MVC (as well as other basic CS concepts) can go a long way towards tailoring the right pitch for a potential client.
For this week’s Learning+Leadership seminar we watched a great video from last year’s MongoDB World featuring Warner Vogels, Amazon’s CTO, speaking on “The Internet of Things” and its impact on society. How we scale data matters, and this video will show you why.