Re: Re (tilly) 2: My code and your stupidity don't mix!

in reply to Re (tilly) 2: My code and your stupidity don't mix!
in thread Would you use 'goto' here?

If you do code reviews and 40% of developers find your code obscure, then possibly you do need to work on making your code clearer. OTOH possibly you need to work on educating them so that they understand your code, and work more effectively themselves.

There's a sampling trap here that I've seen many organizations fall prey to, which is to have the top 50% of developers be the principal (or only!) participants in code reviews. Big mistake if you're vetting code for maintainability. The top half may have no problems with idioms that will stump others. I've seen this happen with Java and C++, as well as Perl.

Comment on Re: Re (tilly) 2: My code and your stupidity don't mix!

Replies are listed 'Best First'.
Re (tilly) 4: My code and your stupidity don't mix! by tilly (Archbishop) on Dec 06, 2001 at 23:19 UTC
Interesting point. However I think that good developers who are on the lookout for it can flag constructs which they understand but they think others might not. Furthermore good developers are more apt to notice the maintainance implications of seemingly innocuous constructs. Therefore if you have good developers who are concious of these points, and who have exposure to what others know (eg through assisting in training, answering questions, etc), I think they can take into account the bottom half in considering maintainability for code reviews. But still I have to wonder at the value of doing a modified usability study to find maintainability implications. Take code from programmer A, hand it to programmer B, and have experienced observer C take notes as B talks through trying to figure out A's code... UPDATE Inserted an important "not" that Corion caught.	[reply]

Replies are listed 'Best First'.

Re (tilly) 4: My code and your stupidity don't mix!
by tilly (Archbishop) on Dec 06, 2001 at 23:19 UTC

However I think that good developers who are on the lookout for it can flag constructs which they understand but they think others might not. Furthermore good developers are more apt to notice the maintainance implications of seemingly innocuous constructs. Therefore if you have good developers who are concious of these points, and who have exposure to what others know (eg through assisting in training, answering questions, etc), I think they can take into account the bottom half in considering maintainability for code reviews.

But still I have to wonder at the value of doing a modified usability study to find maintainability implications. Take code from programmer A, hand it to programmer B, and have experienced observer C take notes as B talks through trying to figure out A's code...

UPDATE
Inserted an important "not" that Corion caught.

[reply]

In Section Seekers of Perl Wisdom