How to initialise an array of structs which contains an array

(Pharap) #21

I’d argue that maintainability is a higher priority, or at least on par with those.
It’s no good having code that does the job if it can’t be deciphered by anyone other than the person who wrote it.
(The story of Mel comes to mind. Mel is an example of a terrible programmer who happens to be clever.)

Code that uses simpler constructs isn’t always more readable.
E.g. switch can often be more readable than an if-else chain.

Not necessarily, it depends on the code and how the ‘lower members’ have been trained.

Assume the code base is using C++,
if the ‘lower members’ have been taught about unscoped enums and C-style casting then they’ll recognise those techniques and won’t recognise scoped enums and C++-style casting,
but if they were taught scoped enums and C++-style casting from the start then they’d recognise those techniques rather than the aforementioned techniques.

(This is part of the problem, a lot of courses still teach outdated approaches that have been superseded, so those approaches stay in use as habit because many simply don’t know any better. That goes for C# and Java just as much as C++.)

Using ‘exceptional’ code does not mean using template metaprogramming and mind-boggling levels of indirection.
Exceptional code is clearly written and uses the best tool for the job.

Sometimes the best tool is something that less experienced programmers won’t be familiar with,
but that doesn’t mean it’s always something that takes a genius to understand.
Often techniques that look scary can be explained in an easy to understand way.
(For example, regexes.)

When it comes down to it the difference between the ‘lower members’ and the ‘higher members’ isn’t intelligence, it’s expereince.

And of course, code using better/more modern/more advanced techniques can be written in a way that even beginners can understand (e.g. std::min and std::max in template form are easy enough to understand even if you don’t know about const references).
Code using simpler/more fundamental techniques can be written in a way that even experts struggle to understand (e.g. the old C !! idiom).

(Simon) #22

Agreed and I should have included this in the list of priorities.

This is the issue with most sites I visit which have a revolving door of programmers due to the outsourcing approach they have taken. Raj 1 is replaced by Raj 2 (sorry for the stereotype) because Raj 1 now has experience and has been bumped up a pay grade and Raj 2 is cheaper for the outsourcer.

Of course, Raj 2 has some skills but he is probably not as good as the rest of the team and will take a while to come up to speed. As soon as he is OK, he is probably going to be swapped out anyway.

I understand your arguments and agree with them in principle. Unfortunately, the reality is sometimes very different!

(Pharap) #23

That’s why I say:

Many companies are run by profit-oriented businessmen who have never even attempted a hello world program so they don’t know and don’t care about the state of the code, pretty much all they care about is “does the code seem to do what it’s supposed to?” and “is the client complaining?”.

They don’t understand code, they only understand business,
so it’s hard to get them to appreciate technical changes that would improve code quality, even if those changes would benefit them somehow (e.g. less chance of bugs).

Some companies genuinely do appreciate technical issues like code quality,
but those tend to be few and far between from what I hear.

This is what I mean about being business minded.
The manager only sees “we can save money by continually replacing the staff”,
they don’t stop to realise how much they’re losing in the process.
They know the price of everything and the value of nothing.

I have a very personal dislike of outsourcing.

(Simon) #24

I more than dislike it !