bool coinBalanceIsPositive(Coins coins)
{
return coins.balance() > 0
}

I also find it really useless if function names contain a reference to the object itself.
for example. because you already know the type of the object so there is no need to write more verbose code.
class AddProcess {
startAddProcess (){…}
}

Also long methode name are more verbose and thus less readable. Instead of writing a long methode that says well it does xyz on object A it might be better to write an abstract name for it and then you can overload it later on for other objects.

drawCircleOnPaper(circle,paper);
should be paper.draw(circle);

The most important thing is consistency if you can do the same thing in slightly several different ways then you have to change something.
dataManager.getCircle()
static_cast(dataManager.get(“circle”));
static_cast(dataManager.get(id::Circle));
dataManager.searchFor(“circle”);
then you should pick one of the methods and not all of them.

Also as a company use auto formatting tools share the settings files and don’t bother your developers how they need to write code.
bool bla(){
…
}
bool bla()
{
}
bool()
bla
{
}
or foo(int bla, bool bla) vs foo( int bla , bool bla ) vs foo( int bla, bool bla )
The auto formatting could even let the programmer format the code as he likes locally and format it correctly when pushing to the repository. I generally prefer the way to type and then let the formatter do the work if the company requires a special flavour.

I think it better to write the best and most efficient code, and if a novice is going to be reading it, they will likely learn from reading it, whereas if I deliberately wrote more verbose code simply to cater for someone with less experience, my output wouldn’t be as good as I could make it and in say a years time when that person is no longer a beginner, what use is my verbose code then?

Nevertheless, the points in the post definitely made a lot of sense.

I’m a noob and I agree with you. I personally think spaces are more readable than dots, no semicolons are more readable than semicolons, and that omitting return types or type hints on methods is confusing, so I basically follow my own style guidelines rather than the “official” one. I mean I have a good reason for doing it (just compare “spot.bark.volume.increase();” with “spot bark volume increase”, but still

”An experienced developer reading code doesn’t pay attention to the vocabulary of
the programming language itself. An experienced developer is
more focused on the actual concept being expressed by the code—what
the purpose of the code is, not how it is doing it. ”

The first step is to learn the language, next step is to be able to create apps with the language. That is the step you are describing. The third step is to create wonders with the language. You are then able to adapt the coding style for what is best to the task.

Experienced developers know how to handle +100K lines of code, how to code so that new developers can understand and work with the code with minimal introduction