There is a growing sentiment towards beautiful code. Everyone seems to be advocating for it. There is a multitude of tools, frameworks, and libraries that want to help you out. But for some of us, the idea of beautiful code is still a strange idea.
Isn’t code just code?
The reality of it is that it’s not. Code is actually a series of translated ideas that are used to compute the necessary experiences for a user. Ugly code can lead to an ugly experience — for both the user and the person maintaining it.
But what exactly is beautiful code? Why does it really matter? And how does it impact your code quality and sanity as a developer?
These are some of the questions we’ll be exploring. When it comes to code, true beauty is more than just the way it looks.
The traditional idea of beauty is based on the physical appearance of things. To be ugly is to be visually unappealing. However, when it comes to code, it’s more than just what we see.
Beautiful code is also an experience.
The way code works from a developer’s perspective is that it’s meant to be used and consumed by the person working on it. This means that it has to be comprehensible as much as it is to be syntactically correct.
The ability to easily comprehend code is based on length and complexity. The longer and more complex a particular class or function is, the more you have to mentally hold in order to digest and process what it’s trying to do.
Beautifully good code is when complexity has been successfully simplified.
It’s easy to write code. However, good and robust code requires planning and forethought with architectural planning and potential impact analysis. Without this, it is akin to building a house without some sort of blueprint.
As a developer of code, you play both the role of the architect and the builder. You can’t successfully construct something that is clear, clean and beautiful without playing both roles.
The purpose of the architect is to plan out how things are to fit together. The architect is able to step back and see where the inefficiencies are in the structures and resolve it before it gets built.
The builder’s role is to construct the code based on the resources available. How beautiful the final structure turns out is based on the developer’s repertoire of knowledge and techniques.
Beautiful code matters because it can indicate how stable your final application will turn out.
The stability of software tends to depend on how well things are able to fit together and its ability to withstand a change in circumstances and purpose for existing.
Beautiful code also indicates a high level of structure and order in the way ideas are translated from the brief and into code. When our translation is jumbled, so is the structure of our code and how they’re written. The ideas surround SOLID was created to give structure to the unstructured way of writing code many developers were operating in before its creation.
Code cleanliness is determined by how to streamline your thoughts are displayed and demonstrated for others to read. Many new developers often fall into the trap of creating mystery novels out of their code without understanding the side effects.
Beautiful code is not just simple but it also has a clear purpose for existing. When more than one reason for existing is coded into a function or class, it becomes brittle to change. This is because partial changes inside a class or function can result in a cascade effect on other parts of your app that may depend on it to work in a specific way.
What’s worst is when you’re working in a team and someone inherits code that is brittle to change. It limits the ability to reuse and reduce the amount of code needed, resulting in longer projects and a higher chance for code bloat.
Your ability to create beautiful code is based on your ability to abstract out the necessary parts, reduce down your code to just the essentials and write only what is required.
Writing beautiful code requires knowledge of standards and techniques. It also requires a deep understanding of certain features, ways of thinking about problems, and how to efficiently translate it over to your programming language.
Your quality as a developer is determined by how robust, effective, and efficient your ability to translate the requirements into something that is succinctly comprehendible across your team.
Code is written for humans as much as they are for compilers and engines. If the person inheriting your code cannot understand it, there’s a high chance of your application breaking in the future.
Beautiful code is also intrinsically lower in technical debt.
Technical debt is something that comes with all code. Higher levels of technical debt can significantly reduce the shelf life code. It can take longer to get things done. It does this by making it harder to implement, upgrade and pivot features. It also takes more time for developers to figure out the working parts and see how they can implement change.
There is a multitude of strategies and principles you can follow to increase your code’s beauty factor. However, there are a few foundational things that exist across different project types and languages.
Acronyms may feel cool and logical at the time but it’s not that fun to read unless you’re already initiated into the project somehow.
The problem with acronyms is that it turns your code into a secret novel that one needs to decipher in order to figure things out. Deciphering takes time. Deciphering takes even more time if there’s no documentation.
Single task is my most favorite principle out of SOLID. Why? Because it’s easy to understand as much as it is easy to explain to others. The rule is clear — your function should do one thing and one thing only.
If it does more than one thing, then it opens itself up to side effects.
Side effects are not fun because you have to deal with the ripple effect if things do change. Then it becomes a tracing game of where it is used and what for. Cleanliness is broken because now you’ve got a potential spider web of dependancy to deal with.
Sometimes we get a bit carried away and over abstract our code based on future predictions. While there’s nothing wrong with creating code to accommodate features that are coming soon, you mustn’t get too carried away.
Over abstraction can leave your code vague and hard to define. There’s a difference between planning for features that you know are definitely in the next few iterations vs. planning for something a year or two down the line.
By then, if you’re operating in MVP sprints, your code and its set of features may look significantly different from how you currently have it. It’s better to grow your code organically and cleanly over time than try to create the perfect app from the get-go.
The thing with beautiful code is that the more you create it, the more you’ll start to recognize the patterns. When this happens, you’ll also start to automatically curate and clean up your code as you go.
Optimization is a skill that is learned over time as you come to know the nuances of your particular language. That is why the deliberate code you write and refactor, the better you’ll get at writing clean and beautiful code.
There is no shortage of various CSS cheat-sheets and quick reference guides online. However, most of them target web designers and only a handful are aimed at the developer crowd. Especially when it comes to backend developers who suddenly find themselves writing frontend automation with CSS selectors.
Sure, you can go ahead and have some fun learning CSS through online minigames. If you are so inclined and have the free time to dedicate to gamified expansion of your skillset – go for it. But if you’re looking for a focused and short CSS selectors cheat sheet made for developers – we’ve created one just for you.
Generally speaking, CSS (Cascading Style Sheets) are awesome. CSS are like libraries for a website, and they have been one of the best things to happen to the way the web looks and works in the past 20 years.
CSS selectors are components in the CSS rulebase and are at the heart of advanced CSS. They essentially save you a lot of manual coding by letting you easily manipulate multiple elements according to their properties.
The latest iteration of CSS, CSS 3.0, added selector options for styling automation. With the selector options added you can write your code to select pretty much any element in the website or webapp frontend.
| Selector Name | Syntax | Description | Example |
| Universal Selector | * | Selects all the elements | * {color: pink;font-size: 20px;} |
| Type Selector | element{properties} | Selects elements based on element type | p {color: pink;font-size: 20px;} |
| Id Selector | #id{properties} | Selects an element with a specified id | #adbox {width: 80px;margin: 5px;} |
| Class Selector | .class{properties} | Selects elements of the specified CSS class | .dark {color: black;} |
| Attribute Selectors | |||
element[attribute]{properties} | Selects elements with the specified attribute | input[disabled] {background-color: #fff;} | |
element[attribute="value"] | Selects elements with the specified attribute equaling a value | input[type=”text”] {color: black;} | |
element[attribute~="value"] | Selects elements with the specified attribute the value of which contains a specific word. | h1[title~="Tabnine"] {color: pink;font-size: 20px;} | |
element[attribute|="value"] | Selects elements with the specified attribute and attribute value with the attribute beginning with specified value (or specified value immediately followed by “-“) | a[hreflang|="en"] { color: blue;} | |
element[attribute^="value"] | Selects elements with the specified attribute with the attribute value starting with specified value | ||
element[attribute$="value"] | Selects elements with the specified attribute with the attribute value ending with specified value | h3[title$="Right Now!"] {color: red;font-size: 30px;} | |
element[attribute*="value"] | Selects elements with the specified attribute where the attribute value contains a specified value | h4[title*="new"] {color: red;font-size: 20px;} | |
| Descendant Combinator | element1 element2{properties} | Selects all specified child descendant elements (element2) under the parent element (element1). | div p{color:pink;} |
| Child Combinator | element1 > element2{properties} | Selects all specified immediate child elements (element2) under the parent element (element1). | div > p{color:pink;} |
| Pseudo Classes | |||
element:link{properties} | Selects unvisited link elements | a:link{color:blue;} | |
element:visited{properties} | Selects visited link elements | a:visited{color:red;} | |
element:active{properties} | Selects active link elements | a:active{color:green;} | |
element:hover{properties} | Selects mouseover hover elements | a:hover{color:purple;} | |
element:focus{properties} | Selects in-focus elements | a:focus{color:pink;} |
As noted at the start of this post, there are a lot of CSS cheat sheets on the Internet and a few of them are even useful for developers. If our short and abridged CSS selectors cheat sheet doesn’t cover your CSS sheet cheating needs, here are a few that might:
Know of a better CSS selectors cheat sheet? Or better better – created the perfect CSS selector cheat sheet? Let us know in the comments!
When it comes to developing robust software, your workspace setup can determine your overall productivity. As engineers, our code workspace also doubles up as the tool that helps us create the code we need. Our overall efficiency depends on how well our workspace is set up.
A well-structured workspace with good processes can help you remain in your flow state longer, keep you emersed and help you stay focused on your tasks. Distractions caused by manual work will eventually slow you down, along with repetitive tasks that contribute to the overall time sinks in your code creation process.
Writing less code is not just about the number of lines you produce or characters you end up typing. Rather, it’s also about how much of the manual and repetitive stuff you can do without.
Here are a few things you can do to reduce to amount of actual code you need to personally create, reduce the amount of time you spend doing certain tasks, increase your overall productivity and ultimately write less code.
There are perks and quirks to writing all your code personally. However, after you’ve been coding for a certain number of hours, you’ll start to see patterns in your code.
These patterns often make up structural templates and foundational outlines in your code. When it comes to using pre-made code, code templates or snippets are designed with best practices. They’re structured in a way that ensures the ability to uniformly create your code. This comes in handy especially for team environments and when you need to share code around.
Snippets offer standardization and when paired with auto-complete, the process of generating code is significantly reduced. This leaves you with more time to think about the code, how it should fit together and what it needs to do to satisfy the feature’s requirements.
AI code completions can not only take boilerplates a step further but can introduce a new level of efficiency. AI based completions can offer you helpful suggestions that you can accept or reject based on context and historical actions.
Rather than just guessing what you’ll type next, code completion IDE plugins, like Codota and Tabnine, act as an auto-code complete tool that also offers up examples that are relevant to your coding context.
In contrast to other plugins, Codota pools usage data together (without actually seeing your code) in order to fuel the coding prediction process and help you create your code faster.
The point of optimizing your workspace is to reduce the number of keystrokes you need to press in order to complete your tasks. The act from moving between the keyboard and your mouse can also break your flow state due to the movement changes.
Predefined actions often address the commonly used actions that developers perform that’s beyond the act of coding. For example, in Android Studio, if you want to quickly jump to the source, you can just press Ctrl + Enter or F4. This will significantly save you a great deal of time in a manual search, especially for larger applications.
When it comes to workspaces, IntelliJ, Android Studio, and Eclipse all have the ability for you to configure keyboard shortcuts to suit your most commonly performed actions.
For IntelliJ and Android Studio, you can configure this via Settings/Preferrences or Ctrl+Alt+S. Then all you have to do is select keymap. You can’t change the predefined keymaps but you can modify any other shortcuts that you may need to access your code editor’s other features.
For Eclipse, this functionality is found under General > Keys.
Not many developers do this enough when it comes to their workspaces. Businesses often use some sort of project management tool such as Asana and Jira to track tasks, project progress, sprints, and burndowns.
If the project management tool is made for developers, chances are that there will also be an integration tool that’s available for your IDE.
In IntelliJ, you can connect your IDE up to a tasks server (available via Tasks > Servers) without the need to download anything in addition. Your team will need to set up a server URL, along with a project ID in order to view and associate your code to the right task.
For IntelliJ and Jira, there is a plugin called Atlassian Connector that will allow your IDE to monitor and update issues without the need to navigate away and into a browser.
When we write code, it’s not always perfect the first time around. Sometimes, when we write code, we spend a good amount of time trying to get braces and brackets in the right places and with the right spacing. They may seem small at first but those seconds do eventually add up to minutes, which can snowball into an hour here and there throughout the entire project.
Sometimes, we find ourselves sidetracked and distracted by the act of cleaning up formats and getting things to look right only to have it destroyed when new code is added.
That’s where linters comes into play.
Code lint is annoying and cumbersome to maintain. It sticks out as minor annoyances that can turn your code into a sloppy mess if not maintained regularly. It comes in the form of physical styling of the code and potential programmatic errors that may not be immediately evident until you run it.
Linters takes away the manual task of checking your code, automatically formats it to standard and flags any errors for you to review. Linters can also help standardize your code across teams and reduce any discrepancies on style and formatting.
This, in turn, reduces your need to worry about how things should look and let you focus on the important parts of the application creation process.
Sometimes you’re not always working on the same machine. Or perhaps you’ve just upgraded your workspace. Whatever the scenario, most IDEs have a sync option that allows you to move your personal settings around without the need to manually set it all up again.
For IntelliJ, you can do this by using the IDE Settings Sync functionality. For this, you’ll need a JetBrains account and all your settings will be synced to this.
For Eclipse, using version control like Git will allow you to automatically import workspace configurations for a particular project into your IDE. However, you should note that issues can occur if you link multiple repositories together and you don’t have them all available on your current machine. This is because your workspace configuration is project-based and linking multiple projects together can cause an issue with syncing.
When it comes to productivity, there’s more to it than just the number of lines you can produce within a time block. As we all know, the process of creating code itself requires other actions that eventually add up to form your day as a developer.
Your flow state plays an important role in maintaining the velocity of your thoughts and setting up your workspace to help maintain it can make or break your ability to maximize the impact of your concentration.
Flow is the moment where you are completely immersed in your work. Breaking flow can add more than just the seconds it took to do the task. The additional time also includes getting back into the flow and picking up your train of thoughts all over again. The simple act of moving between keyboard and mouse can sometimes be just enough to break your flow.
Little tweaks such as using boilerplates, code completion, learning the keybindings, and linters can make your workflow just a little bit smoother. These things can help smooth up what would usually be road bumps in your thought processes, and therefore help prevent you from slowing down every time something minor and repetitive needs to be done.
Data is the backbone of almost every modern app development. Without data, the app is mostly static and will probably won’t be able to do much. Back in the 90s, XML was the predominant methodology used to transmit data over the Internet.
It was a way to format data that was easy to interpret, understand and had strong support across different languages.
The idea behind XML is that it followed the markup format, which determined the rules of encoding documents. Its popularity was widely enforced as developers built API interfaces to interpret and process the XML.
However, XML had its issues such as being prone to verbose syntax.
We often see XML in the space of interface design, such as mobile application development and places where data needs to be structured for styling but not necessarily through HTML, such as RSS feeds.
In contrast to XML, JSON is designed for data and data only. That is why we see its adoption in the space where data is being transferred between applications such as through APIs. JSON’s popularity over XML is partly due to it being pure data that’s formatted in a way that’s also human readable.
Douglas Crockford designed JSON in the early 2000s to be simple and highly predictable in design. While JSON is much younger in comparison to XML, it is more widely used and consumed by APIs, despite only being officially standardized in 2013.
JSON itself is a language-independent data format and was a response to the need for a stateless communication protocol without the need for additional plugins to process.
With the web’s growing support for JavaScript, JSON was created as a subset of JavaScript. This helped form the strong relationship between JSON and JavaScript, pushing XML to the side as a result.
As JSON takes over the web, this leads to the question: is XML still relevant?
Despite JSON being the staple in modern app development, XML exists in many enterprise systems and has moved on from being used as a data transfer format.
It is good to note that despite being used in the data layer, XML wasn’t created specifically for storing and sending data. The idea behind markup languages is that it’s used to structure documents through tags to define elements. XML rise to prominence in the data layer is due to its ability to use custom tags.
XML is now commonly found as part of UI development processes in spaces such as Android, JavaFX, UPF and Xmarin. It is also extensively used in Magneto, in addition to Microsoft based programs such as Word, Excel, and Powerpoint.
Being a markup language, XML makes the perfect platform-agnostic choice when it comes to displaying and styling data. It comes ready and preformatted to the needs of the program and application consuming it. The point of markup languages is that it gives the data structure, with the ability to create hooks and interfaces for other languages to work with.
The thing about XML is that it was being used in a dual capacity – one as a data structure and transfer, and the other as a formatting methodology that is flexible through custom tags.
In comparison, JSON is one dimensional as it has one job and one job only. The existence of JSON is defined by its ability to standardize data structure in a way that is flexible but rigid enough to create easy to understand patterns.
JSON’s purpose is to transmit data in a parseable manner that is less verbose, resulting in faster transfer speeds. The data is structured in a map format, meaning that key-pair values create a high level of predictability.
Being optimized for data and its strong association with JavaScript has led the language to be the preferred data delivery method between servers and browsers.
But unlike XML, JSON doesn’t do too well when it comes to mixed content, and adding meta-data to JSON is impossible without creating additional key-pair value to hold it.
XML still lives today, mainly because it is platform agnostic. It supports Unicode and is often used as part of a data presentation workflow.
This is why XML is still useful to learn, especially in spaces where UI development is required. Native Android development, for example, heavily depends on XML to format UI elements. Being a markup language that has no predefined tags, XML is being employed in spaces where the GUI (graphic user interface) is not a browser.
The verbosity of XML can create high data transportation costs, especially if the data is high in volume. It is less human-readable than other data formats available and doesn’t support arrays in a way that is easy to process and understand.
When used in the data layer, XML can end up unnecessarily expensive due to size. Its optimization is dependant on the developer designing the structure, rather than being intrinsic in its normal modes and structures.
As a data layer, XML is prone to redundancies in structure and is much fitter for purpose in the UI rather than data layer space.
The major perk of JSON is that it is easier for humans to mentally parse through it, making it much easier to work with. Its succinct nature makes it physically light in comparison to XML. As a result, the network transmissions are much faster for reads and writes.
When it comes to JavaScript, JSON is extensively supported and expected. In a way, JSON is seen as almost native to JavaScript. It comes packaged with framework and library setups and used extensively as a ‘map’ for packages, rules, and any other requirements.
The major con for JSON is that it’s difficult to describe the data you’re presenting. This is because JSON works on a strict key-pair value structure. In contrast, XML accepts metadata to help further mark and describe the data as needed.
However, JSON does distinguish between strings, numbers, and booleans, whereas XML represents data as plain text. You can define data types for values in XML via XML Schema, but this is often out of reach and complicated for many beginner developers. JSON’s simple structure and lightweight nature make it much more accessible than XML.
Another major con for JSON is that it lacks formatting validation, meaning at incorrect data structures can be passed into your APIs. The defunct structure is not automatically detected or throw errors as it does with XML.
Despite all this, many modern APIs run on the premise that the data structure is in JSON. There are few new APIs that are XML based due to the popularity and ease of usage with JSON. This in part is due to major front end technologies moving to support JavaScript-based apps. As a result, JSON has become the default when it comes to APIs due to its ability to easily consume and process data.
JSON is often the first pick when it comes to web-based integration because it’s easy to read and consume by apps. Despite having its origins in JavaScript, it has grown to be widely supported, with legacy systems depending on XML to work. JSON has also become the standard data format for many tableness databases, turning JSON into the default and puts it in the forefront.
However, just because JSON is currently the most talked about due to its association with JavaScript and extensive support across different languages and platforms, you shouldn’t completely disregard XML.
The thing with XML is that it has its place in the app development ecosystem and is not fading away into complete obscurity. There’s more to data than just moving it from one space to another. XML does something that JSON cannot do – it can dress it up and allow languages like Java and C++ to create interfaces for applications that may not be web-based.
Native mobile application development often relies on XML to create UIs and scaffolds for data. It also gives the data the ability to be more than just one dimension through meta-tagging and attaching additional information to the XML – something that JSON is not capable of doing due to the key-pair value structures.
Ultimately, choosing one over the other is situational and depends on the framework and libraries you are using. Most of the time, when it comes to web-based applications, JSON is the way to go. For legacy platforms created before the rise of JSON, it may be easier to interface with using XML.