Style is a subtle thing...

[Ed Leighton Dick]

Not to be petty, but both of them need to grow up. They need to realize that personal styles have only a small place in IT development, and the larger the shop, the smaller the room for a personal style. In many cases, if it works, it's right, regardless of whether it looks good or not. Person #2 shouldn't have made the change, but person #1 shouldn't have been offended that someone else changed "his" code.

[Nemanja Trifunovic]

Nishant Sivakumar wrote:

This is the best answer here

Seconded.

Programming Blog utf8-cpp

[Old Ed]

If you understand the code and it works then just leave it alone. It's absolutely ridiculous to get into a pissing contest over style. Additionally, style guidelines should already have been established. Lastly, once you've written code just let it go.

[Doug Rogers]

What you may think is beautiful, is not necessarily what everyone else thinks is beautiful. At my last job, we had a philosophy: When changing someone else's code, use their style. I would leave the code, but attempt to get a coding standard for the company. So when you wanted to change the code to ->, it would be per the company standard.

[pdelayCA]

Maxxx_ wrote:

The beauty of any code lies in the eye of the beholder ... inner beauty that is at once obvious and indescribable

I agree with this comment so wholeheartedly that I put it up on my whiteboard (I also have it signed Maxxx_ [CodeProject]). I cannot seem to move past the memories of the coutless times I have looked over other's code work, and rated them according to maturity of style. I am quite sure that if it were possible to analyze my coding over the past 12 years, you would see a progression of stick-figure crayon drawings gradualy merging into detailed oil paintings. Though my works probably will never come close to the masters of today, they are products of my imagination and assembled through my blood, sweat, and tears. A lot of me goes into everything I make, therefore it is hard not to have an attachment to the code I have constructed. BUT, I am open to new methods and concepts, which means that I will always be searching for ways to improve my craft. I am willing to accept a critical eye and helpful suggestions, as long as they are respectful of the effort I have already applied. Ultimately, my point is that I agree that the "The beauty of any code lies in the eye of the beholder...", whereas it is all to easy to overlook the effort behind the finished product. Keep that in mind the next time you look over someone else's code.

[James Lonero]

Actually, there should be a code standard for the group and/or company that spells out items like this. One of the holiest of the styles is the placement of the braces { }. But, the code standards for the organization should spell this out and the code standard should be updated regularly. But, most places that I have worked have coding standards.

[patbob]

Co-workers. "Beautiful" code doesn't help gets projects done on time, prevent bugs or fix bugs. Putting up with prima donnas is no longer a necessary evil of software development.

patbob

[Fahad Sadah]

Or

//aka
// p_member->p_member->p_member->member

[Ennis Ray Lynch Jr]

Never change someone else code unless you are correcting an error or adding a feature. Stylistic changes, while innocuous must still be thoroughly tested. With regard to the code snippet it isn't even valid anyway in either case as both fail when the level is not assigned.

Need custom software developed? I do C# development and consulting all over the United States. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane

[LenaBr]

Unless the code was once written by your boss and you accidentally use it to illustrate how not to program to all your co-workers.

[dpminusa]

Maybe the example is too simple. What are the objectives of your style guide? Some simple ones include: 1. Self-documenting - use meaningful names 2. Easy of maintenance by all project members - use code you would like to have to maintain yourself 3. No unnecessary/redundant code - use the full recommended, language features 4. No unsafe/incomplete constructs - consider correct and incorrect data may reach this section 5. No insecure code - open to hacks, injections, etc. Do you consider technique and style to be different things? Perhaps your example is more technique that style? To me, style is the art and technique is the science. As someone else pointed out, constructively convincing may be the way to go. I have had success with two opposing members trying to maintain each others code. They may see the point to the style guide and compromise. Not to sound too PollyAnna - then everyone wins.

"Coding for fun and profit ... mostly fun"