Your personal coding conventions?

Given my experiences, I would say, yes, it is because you are able to work with experienced developers.

I use Unity as a hobbyist/indie, my day job is maintaining and enhancing a 1.5 million line cancer collection web application. Due to having to spend all of our funds by the end of the physical year and crappy accounting, we usually bring contractors on the later half of the fiscal year when possible (which is almost every year). So, we've had probably 30 some developers work on it during its 14 year life. Also, since we are government funded our salary scale is not competitive. So, we don't have the luxury of hiring senior developers. They usually only have a couple years of experience and don't hang around for more than a few years when they can command a much higher salary.

While I personally like to have clean readable code, I don't push for it at work for those reasons. In my experience, and your mileage may vary, developers whose code I've looked at that looked hacked together, well, was hacked together and usually indicative of deeper problems. Clean standardized formatting is easier on those new to the codebase and junior developers.

Having said that, I think we can all agree that working, maintainable (at least in my situation) code is the most important thing. My point was that just because formatting and standards are not important to many on this thread it doesn't mean it isn't important. Just that in your scenario it isn't. Some of the comments were making sound as if it would never be important or useful and was just some silly power trip by someone senior.

Now having said that, and that. We are a small team and I don't have time to make everyone format their code correctly, but during code reviews I do slightly scold them for now take the half millisecond to auto format their code before check in.

 

private int _myInt
public int MyInt

void Method(int myInt)
{

}

 

I think consistency in following a coding standard is far more important than the actual standard. Use Java coding conventions for all I care, just be consistent in applying it.

Except for opening braces. Those should always be on a new line and there's a place reserved in hell for those who don't do that

In case the emoticon wasn't an obvious enough hint, I was joking with that last statement.

 

You could of just said the word contractor and I've nodded my head like that churchill dog .

It's just common sense really, I just see a lot of coders slate other coders or dictate THIS IS HOW IT SHOULD BE DONE (one of the minor ones is the public / private thing on this thread) and most times I look, smile and think NAH! It wouldn't make a bit of difference . I very much agree there is no excuse for sloppy code that you don't know where it begins and ends. But neither does it mean someone should dictate standards to someone who actually might know what they're doing.

I'm not saying there aren't better ways, I'm not saying private doesn't have use. In essence, if it works / is readable and reliable then people can do it whoever they want for all I care. That includes my staff..

But anyway I use MANCODE!.

Code (ArnoldC):

1. IT'S SHOWTIME
2. TALK TO THE HAND "hello world"
3. YOU HAVE BEEN TERMINATED

 

My love for your posts grows every hour.

 

What's sad is I was a contractor for the first five years of the project. The one thing you can say about coding is there isn't one way to do most things; nor just one right way; and way too many scenarios for too many absolutes. Kinda what keeps it fun.

 

Something tells me that you are very..... supercilious......

Anyways, I believe making things private is good practice. We don't want to accidentally overwrite a variable in another class, especially when we are working with inherited classes, etc. Also, some things should be public like a speed variable or a jumpHeight variable. It makes sense to make those public. Most people make everything public even if they are not going to change the variable in the inspector / or change it in the inspector and not through code cause they are lazy.

Also, getting the game done right is in everyone's mind. Making a var public or private does not affect this really and Im sure everyone shares that same belief.


PS - I CANNOT STAND SAME LINE BRACES AAAARRRRGGGGGHHHHHH

 

Few people seem to understand the value of the compiler keywords and directives designed to help developers from screwing themselves over. Keywords like private, public and protected and so on that don't have any impact on optimization (unlike keywords like cost which both help you and the compiler) are solely there to save you from yourself.

Theoretically you could program with every class fully public and mutable and so on, but you'd have to be inhumanly good and as soon as you factor in any other coders you're raising the complexity and chances for failure exponentially. Basically good code is not going to happen.

So yes, these things get in the way, they're meant to. The purpose is to make you double check and see if that's really what you meant to do.

It's the equivalent of writing a note to yourself saying "IMPORTANT!!! DO NOT FORGET! BULLDOZER! YELLOW!". If well placed then ideally the end of the world should not ensue.

It might sound awfully fuddy-duddy and like it's just a nuisance for old coders who only have experience and no ideas, but honestly it's the reason why so many apps in the app store suck ass and crash so frequently. Defensive coding practices wont save you completely from yourself, but it will severely reduce the incidence of PEBKAC and make your debugging process about a million times easier and quicker.

To be fair with C# you do have inherent getter and setters so you do get a little leaway there form being overzealous with the use of private scope as compared with languages like C++, however it's better to err on the side of caution, if there is no good reason to make something publicly accessible then don't. Your future self will thank you for your foresight.

 

While I agree with being pragmatic and getting the job done, I disagree that public vs. private is a "minor" issue. If you're saying that things as fundamental as scope management and data encapsulation are "minor" then by extension you're also saying that anything that builds on that - interface design and software architecture - is "minor".

Someone else mentioned that if public variables get used incorrectly then it's the other guy's fault. This strikes me as a complete lack of pragmatism. The fact that "wrong values" for a field exist is a perfectly textbook reason to not make it public in the first place. The fact that someone chooses not to spend even one minute to use tools literally at their fingertips to make sure this problem can't arise is not pragmatic. Pointing their finger at the other guy and throwing a tanty doesn't make the problem go away, and it doesn't change the fact that allowing that gotcha to exist costs far more time than the alternative.

But hey, you get to feel high and mighty when that person reveals how stupid they are, so it's all good, right?

 

#define AGREE

using System.Common.Sense;

private string response()
{

#if AGREE
//since we are in complete agreement
nodYes();

//return appropriate string
return "agree";
#endif
return "alwaysAgree";
}

 

In my life as a NooB Objective-C programmer i did move out functions in other scripts to get a better overview and modularity. It would be interesting to hear from all of you experienced people how you deal with that?

 

Indent 8 characters
* in column 7 is a comment
lots of caps

wait, wait, bad memories of COBOL. When I went to school, we were all taught classes started with caps, variables started with lowercase. Braces on end of line was like, you're so cool you want to be different, but I still like them on the next line so I guess I just wasn't that cool. That was it. Oh, and you had to decide whether you liked camelHumpStyle or under_score_whatever style.

Everything now is just too fancy for me.

 

That's it. I'm writing a compiler for this language.
I can see a lot of common functions becoming Lord of the Rings references though...

PS. New line braces recent convert

 

All in all that whole reply appears to be lets contextually use a single sentence to make a high and mighty (sarcastic) point. Ok I'll nudge one way, the public vs. private thing is a none issue. If a coder makes it an issue, then in becomes an issue..

There are no gotchas in basic formatting and code structure if you know the basics, plus in the real world nobody throws tantys or whatever you're trying to suggest. We sit down and we mentor, fact of the matter is if you work in a team together you're all important as each other and sharing is caring as cliche as that is.

Point being neither you or I can dictate how these things should be done, sure we can guide people, lets say in engine development where you have to make a lot of key components accessible to level scripters / tool makers etc. then we used getters and setters which takes no time at all. If it works well / readable and performs well there is no reason to change it is there? Why you'd try to restrict experienced people with there workflow is beyond me.

You must indent X code X many times at these points (why?) Internet code warriors will slam you for it.
You must use brackets in this order (why?) because I say so.
You must not use public variables for testing (why?) No idea, someone screamed it to me on a forum.

MY oh MY, just use some common sense. Use public statics when you need them, use private, use getters and setters, use overloads / polymorphism / delegates etc. etc. when you need them. Don't dictate how it should be done for every coder and every project.

 

My apologies... next time I compliment someone after recognizing their experience and intelligence, I will try not to leave you out so I don't hurt your feelings.

 

Remember, after saying such truths derived from years of practical experience in your former post, those who want to argue will never truly listen. Heck, I'd be surprised if they did more than skim any reply post, just to find isolated statements to strawman. Those armchair heroes will be the ones already fully convinced that breaking convention is literal heresy.

You are already branded a heretic. It would be surprising if you could convince them to remove that scarlet letter from your forehead.

 

The only things that matter to me is releasing our game succesfully and not recieving thousands of support tickets and draining money in man hours. How we get to that point seems largely irrelevant as I trust my team to deliver, if people brand me a heretic because I don't believe in being overly anal then let them.

Tango talked it through with me, I saw where he was coming from. We discussed as two adults, there were no snide remarks and for me that's good communication. The beauty of my point is even though I may not agree with their point of view it's not wrong either Per makes some good points. Defensive coding in some scenarios is necessary, I've worked in such teams. Here's the thing, coding is scenario based and that's the beauty of it.

I'll quote another old time coder "What's important is what I do at my keyboard, not what others perceive I should do".

 

A lot of what I've read in the past few years about professional software development, employer demands (well, the ridiculous ones I've read people talk about), and conventions (among other things)- it all really reminds me of social work.

You have these people, some who are talented, some who are adequate but amateur (who just need some training, no biggie), and some who are totally incompetent (making you wonder how they exist in the field in the first place).
Then you have leadership, people unlike you. (You obviously know what you're doing, talking about firing the incompetents and mentoring those who need training but are otherwise great people. I've heard every great leader/programmer/intellectual talk about mentoring employees who seem lacking. That is THE thing to do in this field. The newness of the field and lack of training/teaching is big here. I've read a lot of people who say the #1 thing we need in software development is mentoring. "Mentor mentor mentor!" they shout.)

Anyway, you have people, then you have leadership who instead of training the amateurs, mindlessly lumps them in alongside the incompetent / fakers into a single group of "incompetent amateurs who need to be yelled at more."
This results in them overestimating the number of problems with people, fail to see the difference between lack of training and the person not knowing what they're doing, culminating into rules and regulations that they feel should be forced down the throats of others. One hypothesis I have is that this results in mentors yelling at their students, who then later go on websites like StackExchange to yell at other people (thus becoming just like the mentor; Just like they were taught to be). They learned that way right? The mentor taught them useful stuff (true) alongside the needless overcompensating demands (which they lump in as part of what helped them learn "useful stuff", thus it was a good thing, thus they should scold people for not following convention).

There you have it. People screaming at the importance of following conventions which dictate what should be seen as implied rules to follow, to the point of hampering or frustrating the competent people who don't need to be forced to do what is implied common sense to them. Sounds just like the social field to me, lol.


This is exactly how it is in the field I work, which is NOT tech-based. It is social work. Exact same responses though. You have agencies who make demands, that to the intelligent/competent employee, is just idiocy. The competent employees begin to get frustrated for having to do extra crap for no reason, all because the agency is unable to differentiate between good, untrained, and bad employees. Then you have government agencies overseeing all of it, who see different problems, who do the same over-reacting, screwing up the system so bad that even the competent people can't do their job effectively and ALL people have to do an incredible amount of extra work that is entirely pointless and results in absolutely nothing helpful to the leadership. Since it's not helpful, the problems remain, and the incompetent leadership simply CHANGES the method, but retains the same level of uselessness (and thus NEVER fixes the problem).

I don't know why this happens. I don't have enough experience in leadership to even form a good hypothesis. However, I see it very often in professions where it is difficult to measure the competency of the employees. In programming, I imagine that it is mind-boggling for employers to pick the right candidates, ESPECIALLY employers who have to hire tech employees while having no knowledge OF tech. In psychology, it is not an easy thing to measure someone's competency level (whether they are adequate or a genius). For abstract leadership (ex. government overseeing agencies, who oversee employees who work with clients) it is probably not the easiest task to detect who the good ones are compared to the bad ones. I mean, without implementing some kind of group/strategy to better find out.

If programming businesses are anything like most businesses, and if software engineering professors are anything like most professors, then there are great ones, good ones, and a whole hell of a lot of incompetent leadership ones. Leadership which spews out all these people who become internet code warriors branding others as heretics for not following their taught 'religious' beliefs of overcompensating convention.

I assume in both professions, since I know in psychology, anyone with experience and intelligence can better spot the bad employees. I'm confident that confident leadership doesn't have a lot of these problems, and that is why they feel no need to force needless things on their employees. Of course, treating your employees like human beings (and not animals to be yelled at) is also seemingly rare in business.
Still, we can all be fooled by the fakers. I've heard of employees who outsource their entire job to India. They literally do nothing, while their employer pays them high wages to pay low wages to India workers. Crazy stuff.


That's what I know anyway. I'm sure it's not entirely accurate, possibly even wrong in some cases, but it's a bit how the world works. At least some parts of it anyway.

 

I guess I could have summed all of that up in one sentence:

Rules & Regulations can never take the place of proper Leadership & Teaching.

 

My only convention here is to use upper case letters for the first letter of each word in the variable name, and use meaningful names that are specific enough not to have clashes. I can't stand the stupid convention of having a lowercase first letter for the first word, it is so incredibly unintuitive and is one the thing that drives me nuts about some of Unity's API. The closer to normal english the better.

 

<3 to you as well.

Especially the part "The closer to normal english the better."

It makes so much more sense to me, for conventions to...well....make sense...lmao.

That is why I prefer heavy commenting over convention. Just my preference anyway.

 

Oh you make me so mad.

 

Definitely supercilious.

 

I do heavier commenting too. Almost every line I comment.

 

I don't know how you came to that conclusion, since most of what I said there was only tangentially related to the thing I quoted. The quote was important for context, but it was not the totality of the conversational tangent I was responding to. Everything after I mentioned "someone else said..." was about stuff said by multiple people over a number of posts.

 

It's devolved into a meandering topic, and there's very little actual information going out (I'm guilty of it too) - possibly because it's hardly a new topic around here. Shall we let it die?

 

Die of natural causes, yes. Don't kill it though.

 

http://docs.unity3d.com/ScriptReference/SerializeField.html

I looked at this after reading this thread and wondered if I should be using public or private for things like textures and it seems to imply I should basically never be doing this with Serialize.

I am curious to hear more about this and what is the correct way.

 

While I used to do what the docs say, these days I'm very conscious about the difference between the code interface and the inspector interface of a component. Public and private are about code, [SerializeField] and [HideInInspector] are about the Inspector. When I write my code, I make it so that both interfaces make sense for their target audiences and use cases.

If I wouldn't make something public outside of Unity, I won't make it public in Unity, I'll mark it private and add [SerializeField] if I want it configurable in the Inspector. An example of this could be a MaxHitpoints field - it makes sense that it's editable at design time, but it makes little sense for that to be arbitrarily changeable at runtime. (For instance, even if I did want it to be changeable I'd almost certainly want to clamp it to positive numbers, and I'd probably want to make it an explicit method call... though the latter is my stylistic choice.)

Similarly, if I want something public for coders but don't want it in the Inspector, I'll mark it public and [HideInInspector].

I'm also getting in better habits about being more explicit either way. It's not about just making the code function, it's also about making my intention clear. If something public is hidden from the inspector then it's clear that it's intended for coders to be using, and that it should be expected to change at runtime. If something is private but serialized then it's clear that it's intended for designers and that the code probably doesn't expect it to change at runtime, and so on.

To be honest, I think Unity's documentation on stuff like this is more about making things accessible than about best practices. Having said that, it could simply be that originally those explicit attributes weren't available and the documentation hasn't ever been updated to reflect them. Or, it could be that (programmers being programmers) the documentation is in fact correct - we don't in fact "need" these - but they're available for people who want the extra control.

 

Camel case everywhere and braces on new line!

I wish I had this habit!

One question for you guys, do you comment on the line before the statement:

Code (csharp):

1.  
2. // some foo
3. public int foo = 1;
4.  

or do you comment on the same line like:

Code (csharp):

1.  
2. public int foo = 1; // some foo
3.  

 

I use pre-comments to explain and post-comments for things that need to be done (since they stick out). Although I'm probably not consistent about that. I probably use post-comments just as much to point out warnings.

 

For me I comment like this

Code (csharp):

1.  
2. string helloWorld = "Hello World!";  // String value containing the text "Hello World".
3.  
4. /// <summary>
5. /// Comment about the following function or procedure goes here with a detailed analysis of what it is for and how it
6. /// "should" work.
7. /// </summary>
8. public void HelloWorld()
9. {
10. Debug.Log(helloWorld); // Write to console log the string value.
11. }
12.  

More complexity in the game code means more commenting...

Code (csharp):

1.  
2. public string results = string.empty; // String value that will contain the results of the function CalculateThreadHostility.
3. results = CalculateThreadHostility(8); // Call function and pass into it the required parameters.
4.  
5. /// <summary>
6. /// Comment about the following function or procedure goes here with a detailed analysis of what it is for and how it
7. /// "should" work.
8. /// </summary>
9. /// <param name="level">A description of this parameter specifying the data type and what its purpose is and how it will be used in the proceeding function or procedure.</param>
10. private string CalculateThreadHostility(int level)
11. {
12. return = level > 9 ? "Mild" : "Hostile"; // Ternary statement will return result as a string value.
13. }
14.  

 

I typically do comments on the line before statements, except variable declarations, which are on the end of the same line.

 

Thanks for the explanation. I think I might try switching to this convention in my next project. Previously I had just been doing as the documentation suggested.

 

I currently use the doxygen javadoc style for comments of functions etc. So I comment before classes and functions, on the same line as variable declarations and ends of longer blocks and at the start of the block for branching statements.

(C++ example as that's what I'm using 99% of the time these days, but it's really the same style in almost any language).

Code (csharp):

1. #ifndef __MYCLASS_H_
2. #define __MYCLASS_H_
3.  
4. #include "somefiles.h"
5.  
6. #define SOME_DEFINE_FOR_DEFAULT_LOTS_AND_LOTS    1000000   // Really, lots
7.  
8. /// @file
9.  
10. namespace space
11. {
12.  
13. /// @addtogroup DOXYFLUFF
14. /// @{
15.  
16. /// This is my class, use it wisely
17. /// @remarks     Usage :  something important with examples and clarity
18. class MyClass : public ParentClass
19. {
20. private:
21.   int lots;        /// This is a lot of stuff, and it's used for stuff, like real stuff
22. public:
23.   MyClass()
24.   {
25.     lots = SOME_DEFINE_FOR_DEFAULT_LOTS_AND_LOTS;
26.   }
27.   virtual ~MyClass()
28.   {
29.   }
30.  
31.   //----------------------------------------------------------------------------------------
32.   /// This function does something to the class and is publicly accessible
33.   /// maybe some usage examples/remarks
34.   ///
35.   /// @param [in] aParameter    A parameter for something
36.   ///
37.   /// @return  true on something, false on some other thing
38.   //----------------------------------------------------------------------------------------
39.   bool MyFunction(int aParameter)
40.   {
41.     if (aParameter > lots)
42.     {
43.       // Here we do something because aParameter is higher than lots
44.       // which has this implication
45.       lots++;
46.     }
47.     else if (aParameter < lots)
48.     {
49.       // Here we do something else because this has this implication
50.       lots--;
51.     }
52.  
53.     return aParameter == lots;
54.   }
55. };  // class MyClass
56.  
57. /// @}
58.  
59. }  // namespace space
60.  
61. #endif  // __MYCLASS_H_

So much comment fluff can actually make the file less readable at first until you get used to the style and verbosity, but it's the price you pay for using a system like doxygen. I now find this style pretty easy to read and with contextual help and tooltips in an editor via visual assist, resharper or even bog standard intellisense it really makes this pay off and speeds up workflow.

 

@Per, that looks like pretty much how I do it, too. I also agree that over-commenting isn't a good thing, since it's more to read and more to maintain.

When writing comments, keep their purpose in mind: they are to help future developers understand the code more quickly. If something doesn't help with that, don't write it. As a rule of thumb any competent coder can read what code does but often it's not clear up front as to why it's doing it. So when I comment stuff it's typically because either a) a piece of code ends up being counter-intuitive (or containing hacks) or b) it's not immediately obvious why I'm doing something and explaining it in-place will save people (including me!) from having to investigate later.

Just to add to what I was saying about making my intentions specific, two very valid examples of that which I didn't give are private with [HideInInspector] and public with [SerializeField]. It's redundant in the sense that those are the defaults anyway, so the functionality doesn't change. However, it makes it explicit that I'm intentionally using what happens to be the default - it has been considered and was an actual decision. I specifically wanted that thing to be public for coders and also I specifically wanted it to be in the Inspector for designers.

Finally, there's the case of using both [SerializeField] and [HideInInspector] regardless of the scope. I'd use this where I wanted some data to be persistent but to not show up in the Inspector. I typically use this where I'm using a tool to set up something behind-the-scenes at design time, so I don't want designers messing around with the data directly, but I do still want it stored. In this case it doesn't matter if it's public or private data, since either way the Inspector/serialization behaviour will be the same.

(It could be argued that just as I personally consider the code and Inspector interfaces to be separate things the Inspector and serialisation interfaces could also be considered separate. I don't personally think there'd be any benefit from that, though, as long as you properly understand how the serialisation system works with regard to public/private/[SerializeField].)

 

eww comments.

lol

 

My style revolves around two things, readability and maintainability.
If it ever changes, it's always for the benefit of one of those.

Aside from the usual naming and brace wars, the biggest impact on my ability to read my code is the color of it!
I've set my IDE up to color code things the way I like. Method name declarations and uses are a certain color. Properties have their own color. Classes have their own color.. etc.
You would be surprised at the impact it has on your recognition. Without it I find myself having to consciously read the code for more context, whereas with the color coding I can skim-read almost subconsciously.



Re commenting, I have always subscribed to the view that code should be self commenting - I should be able to have a quick look at a block of code and be able to understand it easily without referring to a comment block. If I cant, I should refactor it. If I can't refactor it, then I think about commenting it.
I personally find it magnitudes harder to read someones code when they've commented the balls out of every property and method. I feel that if you have to go to those lengths then maybe you should rethink your naming conventions.

Re private vs public, etc --
Sure you can drive a car without a seatbelt... it's not hurting anyone.. until you crash.
Generally the conventions are there for a reason.. and you don't appreciate those reasons until something goes wrong.



/2c

 

Code (CSharp):

1. #define MY_DEF
2.  
3. namespace MyNamespace{
4.  
5.     class MyClass{
6.  
7.         //Public example variables
8.         public int myVar; //Variable that holds an integer
9.      
10.         //Private example variable
11.         private int myOtherVar; //Another variable that holds an integer
12.  
13.         //Method that does nothing
14.         void MyMethod(){
15.  
16.          
17.  
18.         }
19.  
20.     }
21.  
22. }

So I tend to start the first variable word with lower case and successive words with uppercase; I have my namespaces, classes, and methods have uppercase for all words; I define constants in all caps with underscores between the words; and I put comments above the statement/block unless a line needs special attention (such as a variable declaration).

I don't really understand why everyone hates same line brackets so much. To me, next line brackets disrupt code flow and makes it harder to read; I still don't find next line brackets unreadable (unlike some of you who seem to talk about same line brackets as completely unreadable).

 

I try to follow this:

http://msdn.microsoft.com/en-us/library/ff926074.aspx

as long as it's new project or small project that can survive change. Reasons are various:

- removes ego from talks ("I feel same-line brackets are better, but cannot explain why" is obsolete, we agree to external standard)
- makes your code compatible with non-Unity scripts

Last one means you can grab open source lib and put it within your repo without worrying "oh gosh, I need to reformat all of this"

(for ppl saying you can always reformat automatically: um yes, then you put it in repo, then new version comes and you have no idea what changes because there are 200 lines of diff and you need to go through all of them 0o. Ok, you can reformat back, or format new version, unless... you needed to do custom changes to script then you cannot simply copy file and reformat, ugh you know what I mean)

And for any other language find most common denominator in standards and use it (long live automatic pep8! you're amazing)