Style is a subtle thing...

[macu]

I definitely avoid this for three reasons: 1. It winds people up, sometimes a lot. 2. You look very stupid when you amend something for style and accidentally introduce a new bug. 3. You introduce changes into the source history in your source code control software that aren't meaningful and actual changes become harder to see. A guy where I work got hold of a copy of resharper and did all of the above in a big way (yep bugs too). I use resharper and it's very good but it's not a good idea to randomly open other people's code with it just to reformat...

[urbane tiger]

The following's relationship to your question is somewhat oblique, but nevertheless I think it's germaine. After examining the first module I'd written at what was then my new workplace, the chief code stylist told me, "We do not allow use of computed procedure calls (function pointers) round here". "Why not?" I asked. "Because the compiler has a bug" he replied. "What bug? Show me" I demanded. "This one" he replied, pulling a 15x11 listing from the shelf and referring me to the apparently errant code, which did indeed make use of computed procedure calls. Äfter a few moments of reading I asked "Does it fall over with a bounds error?" "Yes. How did you know that?" he replied with some surprise. "Because there's a GOTO in here that jumps into the middle of a FOR loop" I smugly replied. Needless to say I was able to lift the ban on computed procedure calls, and after that many other constraints on the liberty and freedom of programmers to write the code that they thought best suited the problem. In later years, with some help from the likes Edsger Djikstra and Nicklaus Wirth, I was able to impose an embargo on the use of GOTO, not to be used without prior approval of the then chief code stylist, who was by then -- you can guess who. I had great relationships with my colleagues, especially Deb.... and Elsp... and ...., salad days long gone.

Multi famam, conscientiam pauci verentur.(Pliny)

modified on Wednesday, April 29, 2009 2:56 AM

[Lonnie R Thomas]

code writing is an individual thing. Instead of automatically changing the code or remarking it just talk to the person. Change just for the sake of change is inappropriate. But good communication with your coworkers is the most important issue here. In my case the more experience programmers look at my code and suggest mayber a better looking way but do not hassle me about it. When the end result is the same. Simply talk to each other like adults. ;)

Lonnie R Thomas

[Bob1000]

Speaking as a person who has to modify (fix) code many years after the writer may have disappeared (grrr!). Readable and understandable code first!!!!!!! The code writer ought to learn its not just writing the code in the first place it has to be maintained, if nothing is said nothing is learned!

[sketch2002]

Jim Crafton wrote:

and has a serious sex addiction!

Unless HR is the one with the... how did he put it... Oh yes:

Jim Crafton wrote:

willingness to get drunk at the Xmas party and fool around in the stationery cupboard.

[Nish Nishant]

5. This is the best answer here. :thumbsup:

Regards, Nish

---

Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
My latest book : C++/CLI in Action / Amazon.com link

[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"