Your donations tell Kuovonne that you value her content and want her to continue publishing. When I evaluate a piece of code, I look at several traits.
Working code needs the correct syntax and logic. Quality code also needs organization, voice, and efficiency. Each of these traits can be learned and improved independently. Becoming good at all of these traits leads to
Syntax
Syntax is the grammar of the coding language. An English sentence needs the correct types of words, in the correct order, with the correct punctuation. So too, code needs to follow the rules of the language in order to make sense. The main difference is that humans can usually still understand an English sentence with grammar issues, but even a tiny syntax mistake can render code unreadable by a computer.
Syntax errors can be exceptionally frustrating for new coders to because they can be difficult to identify. Here are my recommendations for dealing with syntax issues: Don’t let syntax errors determine your self-worth or your ability to write code. Even the most experienced coders sometimes type syntax errors. If your code editor flags potential syntax errors, address everything that is flagged (or at least understand why the code is okay). Write with a style that makes it easy to check syntax. For example, indent blocks of code so that you can easily see where each block of code begins and ends. to learn the syntax for your language or library. Look up the syntax as often as you need to, until you are fluent. Avoiding syntax issues in the first place is much easier than going back and fixing them after the fact. Logic
The logic in your code determines if your code produces the correct result. If the logic is wrong, it will produce the wrong result.
your code to make sure there are no logic errors. For very simple cases, the coder can simply understand the logic to decide if the logic works. However, as code gets more complicated and is run in different environments, it becomes important to actually run the code to test that the logic is correct.
Organization
While organization is related to logic, it is possible to have working logic but poor organization. Organization includes how code is chunked into sections both within and between functions. It also includes the order of sections of code within a file and across files.
Well-organized code has several benefits.
Debugging. It is easier to follow the logic and identify problems when the code is organized. Maintenance. When maintaining code, you can identify which section to add, change, or remove, without accidentally making unintentional changes. Reuse. Well-defined sections of code are easier to reuse in other areas. Voice
Just as different people and sub-cultures have their own unique ways of speaking, different coders have their own ways of writing code. The coder’s voice includes a wide range of features:
naming, scope, and data type. White space. Use white space and indenting to reflect the organization of your code. Vocabulary choice. Different coders tend to prefer different types of vocabulary. For example, different coders might prefer different types of loops. More experienced coders tend to know more language features and library functions, and thus they use more complex vocabulary. Pick up more vocabulary by . Expression length. Some coders chain together long expressions while others prefer shorter statements. In general, novice coders tend to use shorter expressions, just as children tend to speak in shorter, simpler sentences than adults. Expressions that fit on a single line are easier to read than multi-line expressions. Block length. A block of code might be a single loop or it might be an entire function. Blocks that fit in a single screen are usually easier to read than longer blocks; although sometimes long sections of boilerplate type text are necessary. Pattern choices. Follow best practices such as isolating concerns, guard clauses, separating high-level and low-level logic, abstractions, etc. Avoid anti-patterns such as unnecessary loops, over-complications, and code for future features that might never happen. If you have a style guide, follow the style guide to match the voice of your organization. Aim for clarity in your choices—don’t use obscure vocabulary, long expressions, and fancy patterns just to look impressive.
Efficiency
In general, code that runs faster is more efficient and better than slower code.
Avoid running code that does not need to be run. Remove code that will never run. Avoid reading or writing data data unnecessarily. However, efficiency is actually the least important of all the traits. If you have limited time and see other ways to improve the code, you are usually better off in the long run addressing those other issues first. If you make the code more efficient, then need to reorganize the code, any efficiency improvements may be lost. On the other hand, if you improve the organization of the code first, you may find that it is also more efficient.
The content in this guide is free, but creating it takes time and money. If you like this content, .
