How to Adjust to Coding Standards?

[JOSheaIV]

Okay so this is for those who do or have developed for a living.

Long story short, we had a meeting today where we finally set up standards for writing our code. Most of them I was sadly the blacksheep and lost my arguments (they mostly came from the one developer who got the ideas after he started using ReSharper).

Anyway, I am not liking these to much, some I think are just ... well all they do is create cluttered code, and are just going to cause more pains when it comes to debugging. But even though that's the case, I know I have to adjust, which is going to be hard (especially since of the whole team, I am the only who goes home and develops on his own time, so I have my own standards, and they are that way for a very specific reason, and have fine tuned over the years).

Now I will point out while I have been with the company less then most of the group, but they do come to me for questions on possible bugs, or how to address something, ext. Also, I feel I can usually debug faster then most in the group (mainly because of MY standards).

So any one else been in this boat? How did you adjust? Was it hard? Details please (maybe a trick I am overlooking)

[rubberman]

Yes, I've been there! In my opinion, less is more, and simpler is better. Good naming conventions are very useful, such as m_Varname for scalar member variables of a class, and m_pVarname for member variables that are pointers. It keeps them from becoming conflated with other variables such as Varname. You can easily go overboard with this, but the principal is appropriate.

So, corporate/group standards or not, you need to have your own standards for coding and adhere to them. Since you are working with a team, you need to make them compatible for the most part, or at least not too incompatible! :-) I have found that an occasional personal discussion with the other developer(s) about these issues can help to level the playing field and come to some sort of agreement as to what would work for the team in general. I try to start the discussion like this - "What do you think about using this construct?" or "Can you explain to me why you want to do this that way?". In any case, treat them with respect and you will probably get some in return.

[deceptikon]

It kind of depends on the parts you're finding difficulty with. If you can be more specific, I may be able to offer some advice. Though it's mostly just buckling down and taking more care as you write, which can be beneficial in that it forces you to think more.

In my experience, I've been on the winning side more often than not in terms of coding standardization, but there's definitely a certain measure of compromise. And yes, things that are completely different from my personal style clash for a while. However, there are some aspects of an office coding standard that I've adopted into my personal style.

I have my own standards, and they are that way for a very specific reason, and have fine tuned over the years

That's all well and good. I'm sure we're all the same way. But after many years, I find that my style evolves. What I thought was ideal 10 years or even 5 years ago is woefully suboptimal to me now. The important thing is to be willing to embrace changes, because they might turn out to be your next favorite thing. ;)

[mike_2000_17]

I think it boils down to picking your battles. The small stuff like naming conventions, indentation and stuff like that is not worth breaking a sweat for, just follow the guideline and get used to it, and build your finger muscle-memory for it.

But coding restrictions that you think lead to sub-optimal designs or bad code ("bad": poor performance, unmaintainable, unreadable, unsafe, etc..), then you should probably just sit on it until you find a good opportunity to demonstrate (with real code in the real project) why your way would be better (better: performs better, more maintainable, more readable, safer, etc..), and then, use that real example to make an argument to change that restriction. And either way, doing this will be good for you, because it will either confirm and demonstrate that you're right to do things that way, or debunk your own practices as being either equivalent or worse than your company's coding practices.

[JOSheaIV]

Thanks for the input everyone.

I'll give you an example of one I am not a fan. We have these variables that are used to talk with a database, each represents a table (they use DataTables and what not in C#). Anyway, when I add one, and initialize it, it's always the same process. Create the variable in this region, then go to the other region and initialize it, 2 lines of code. Well now we are going to use getters, so we have create the variable, then create a getter that does a null cehck to see if it has to be initalized. This is bulky code, and can be really bad when you have 20 of these objects (they also want to do ith with another type of variable we have, and those can easily be 10+). To them it's easier, to me it's clutter. They argue they might forget to initialize it, but I told them what I do works all the time. However, the reason we are doing this is the one dev, who discovered ReSharper, had it tell him to do this. He seems to follow what ReSharper says, assuming it's the best thing.

I have used the quote many times in the office, one a professor taught me. It's not how efficent the code is, it's how easy it is to maintain.

Now granted they want to do this concept where we are going to move the code to another layer, and inherited class. Personally I am not a fan of the idea either cause I feel it will make debugging slower as I have to switch between pages to see what this part does and what that part does.

I did try to compromise with stuff, and make my point, but I feel it went on def ears (tehre was another piece that I was thought was bad because we would use it most the time but had to make an exception for this and that due to some converters. I made a compromise to say "hey let's join these and then we all win and no exceptions" ... which results in me having to fix the base code and prove it works to get it that way)

Maybe I am trying to use a bad habit I don't know. I will admit my standards have greatly approved over the years, and I have perfected them. But one of my arguments is "I can debug a lot faster when it's like this". Mainly because of how it looks visually and easy to navigate. That's what's really concerning me is the debugging