38
Why prefixes in the first place?
The prefix for function names is a C practice that intends to avoid naming conflicts.
This is especially suitable in big projects, where different teams could easily come with do_this() and do_that() in different subcomponents of a large codebase.
Since C lacks of a namespace or a package feature, the prefix is the most ...
16
There are two important types of naming collisions here. You are correct in that the compiler won't have any trouble differentiating between the functions due to scope rules. Your problem is that you still have collisions inside the programmer's brain.
Think about it this way: if you have 8 modules that all have a process_data() function, and you get a ...
16
There is another reason to use prefixed names even for file-local functions: they can be navigated with simple text search and text indexers without full analysis of language scoping, such as id-utils. Given that C projects often have their history going back to 90x and even earlier, it is an important reason.
8
I think the important piece to understand in your examples is that a Price should not be the same as a double--for starters, doubles can't represent monetary amounts correctly. But Price has other restrictions--it can't be negative, it can't have more than 3 decimal places (in the US), etc. Those are type invariants. They prevent you from making mistakes by ...
3
It's worth pointing out that double is not an abstract type. It's a concrete one. Price isn't an abstract type either.
If you had some AbstractScalarType which abstracts across all scalar types, then AbstractScalarType could still specify (but not necessarily implement) a method roundToValidValue. That said, there is probably little value in such a class ...
2
In short
Option 2 is better and there are objective reason for this. And yes, the approach can be improved.
More details: why option 2 is to be preferred
Option 1 lacks separation of concerns. What does this mean?
Imagine that one day your project could afford to hire a team, with an expert of serialization, another specialist for iteration, and a guru ...
2
The most important recommendation is:
Comment the unexpected, not the obvious!
A comment like this is useless:
// Adds a to b and write the result to c
c = a + b;
It just repeats what the code says and you shouldn't write comments for people who don't understand code as if they don't understand code, they won't read any code and if they don't read any ...
1
The author of the rule "use most abstract type" probably did not mean replacing single-field classes with their content. After all, double is not a supertype to the Price. I think they would rather meant some interface Price which could be implemented with different PriceImpl classes. If it is still justified to be used here is another question (by my ...
1
In reality, lots of times your code is just fast enough, so you do nothing.
If it’s not fast enough, lots of times you don’t need to optimise, you just have to figure out what you did that was completely stupid and killed performance, and stop doing it. That has been my experience in recent years, that when something was too slow, it was because of someone ...
1
Somewhat an odd answer but, the best kind of comments are *no comments*.
If your code is clear, clean and honest:
You do NOT need comments.
Comments lie and are hard to maintain. (one of the many links on Google talking about it)
Try to name your method to hint the intention, adhere to the single responsibility principle whenever possible and your code ...
Only top voted, non community-wiki answers of a minimum length are eligible
