Go to books ↓
How would you define good code? This article gives a pseudo-scientific answer to that question after asking a sample of 65 developers that same question.
The focus of this article is how readability and maintainability is improved by replacing simple types with domain types. Consequences of introducing domain types is both a closer relationship between model and implementation, and that the domain types establishes a conceptual foundation making it easier to extend and adapt the application for future changes.
Programmers need a good working knowledge of at least the common mistakes, the frequent cases that average programmers tend to miss, to work against. You are tester zero. This is your responsibility.
CSS is an unstructured language. Everything can be accomplished in twenty-five different ways. (And if you’re part of a team: everything will be accomplished in twenty-five different ways.) The biggest problem is arguably CSS’s biggest selling point: there’s a quick fix for every problem. Just put a new rule at the end, upping the selector’s specificity a bit.
Understanding underlying logic of requirements is a fundamental skill for a programmer, because of the challenge of changing requirements. The requirements always change, but they often do so within an implicit logic.
You are told that microservices make the whole thing so much easier, and each component is so small that you don’t need to put the same amount of care into it. Is that true? No, it isn’t.
Developers usually write the code for the perfect scenario without considering anything that could go wrong.
How we behave when writing horrible code is the ultimate litmus test for developer competency.
It’s possible to construct a simple mental framework that can be used with any language or library and which will lead to good quality code by default.
If you can name a function really well, it probably does one thing and one thing only. This means you’ve figured out a decent way to separate your concerns, which means that often, the name is really all you need to know.
It looks like Facebook is getting the textbook results of ignoring code quality.
This is a real worry these days. I've heard it from lots of lots of developers. The years tick by on their projects, and all they ever seem to do is add to their CSS, never remove. It's not just a feeling, I've talked with companies before that track hard data on this. Over five years of tracking the size of their stylesheet, and all it's ever done is tick upwards in size.
There’s a recurring theme in the programming community that’s tied to finding “better ways” to write “modern software.” And so if we pay attention to the conversations surrounding software development today, we’ll quickly realize how important it is to separate the wheat from the chaff: what’s useful and what isn’t.
To find implicit concepts and make them explicit is a very powerful way to improve code. But, sometimes it is hard to judge beforehand which concept is important enough to make explicit. We try to make good judgements, but sometimes we miss.
To make implicit concepts explicit help us to over time close the gap between the code and the understanding of the business domain. It is not uncommon to in the process find bugs or crucial misunderstandings, that then can be addressed in a proactive manner instead of popping up as nasty surprises later on.
Moq is, as the stats would indicate, a pretty nice codebase. But, as with just about any codebase, there’s plenty of room for improvement.
Debuggable code is code that doesn’t outsmart you. Some code is a little to harder to debug than others: code with hidden behaviour, poor error handling, ambiguity, too little or too much structure, or code that’s in the middle of being changed. On a large enough project, you’ll eventually bump into code that you don’t understand.
Looking inward at an IoC framework, we see that it does indeed keep its own type coupling to a minimum and that it writes testable code and then tests that code.