Re: C++ - how to convert string to uppercase/lowercase
On Dec 19, 11:07 pm, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Dec 19, 10:25 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
No shop, start up or not, should impose standards that
have no reasoning behind them. Consistency in style makes
code easier to read and to modify. All successful shops
strive for some consistency in style.
Collective code ownership is a great way to achieve
consistency in style.
I'm not sure I understand. The code I write belongs to my
employer. Some employers have very strict coding
guidelines, others don't.
The development team owns the code, collectively on behalf of
their employer.
I don't know where you get that. All of the code which I've
worked on professionally has been done as a work for hire. The
company who paid for it owned it, and the people who wrote it
had pretty much no say with regards to what was done with it.
No single developer is responsible (has ownership of in
management speak) any one module.
Responsibility and ownership are two different things. Whoever
checks the code in is responsible for it meeting the established
quality requirements.
Everyone works on every bit of code. For this to work, the
team has to have a common style, which will quickly evolve in
the absence of a coding guideline. Coding guidelines should
not be cast in stone, they should be owned by and updated by
those who follow them. As you said further down, a unified
style improves programmer productivity, that works best if the
programmers shape the style.
That more or less "va de soi" (not sure how to say it in
English: "goes from itself"). Coding guidelines are written by
the coders. And the evolve in time. That's always been the
case---nothing else works. (And coding guidelines, and
everything else in the process, must be sold to the programmers;
nothing imposed arbitrarily from above ever works.)
Coding guidelines are imposed for real-world, practical
reasons. A common, unified style improves programmer
productivity. It makes code reviews easier and more
effective, for example (which also improves software
quality).
It also breaks down those stupid my code/his code barriers.
It's the company's code.
Exactly. Many places I have worked have silos within
projects, person A "owns" module Z and person B "owns" module
X.
Well, I "own" the library at my site:-). I've written it over a
number of years (too many to count), and no one has ever paid me
for it. But I think you mean something else by "own", although
I can't figure out what: if you are paid for your work, then
whoever pays you owns the copyright on the code, and thus the
code.
And you can't mean the responsibility for the code, because you
want all of the individuals in the team to feel responsible.
When the code works, all of the people who worked on it should
feel proud. The important point here is creating the
understanding that it is a team effort; no one person can do it
himself. And the person who actually coded module X needed the
help of the person who designed it, and the people who code
reviewed it, and the people who tested it, and the people he
talked to while he was coding it, and even his boss, who made
sure that all that support was there, that he wasn't constantly
interrupted by other things, that he had the necessary
resources, etc. The person should be proud of what he has done,
but proud of it as a contribution to a team effort.
A good analogy might be American football. A person who scores
a touchdown can be proud, but so can the person who blocked for
him. And neither should think he did it himself, or there soon
won't be anything for anyone on the team to be proud of.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34