Well I'm going to drag myself away from BF3 (until Back to Karkand gets released anyway) to start hacking into the code in order to add all of the updated InSim packet support and other features.

To that end, I reckon it's about time we discussed things like coding standards and feature sets. These discussions will directly affect the existing code base in that it would be good to clean it up considerably, as some of it is quite hacky and confusing with a lot of vars called the same.

Firstly, I'd like to suggest that we use a naming convention like the PRISM project does in the thread http://www.lfsforum.net/showthread.php?t=70147. Their convention is to:

1. Use tabs for white space, and the tab width should be equal to 4 spaces.
   
2. All objects, classes and references use Camel cased naming and:
   1. Variables, instances and Functions start with a Lowercase character e.g. $thisVar, $newClassInstance or thisFunc()
      
   2. Classes start with an Upper case char e.g. ThisClass
      
3. Constants or Enums use upper case e.g THISENUM
   
4. We ask that you make the function names as clear and as concise as possible, not matter how wordy e.g. $leftRearTyrePressure or ConvertIntToString()
   
5. Source code formattingcan be at the coders discretion with the exception of tab spacing, however keep in mind that splitting over lines may help readability.
   

Those guidelines actually affect about 60% of the codebase in that a lot of variable and function names are not quite concise enough or the incorrect case. Fixing the big ones isn't a major problem and can be done in a few hours, although this brings us to the next point...

Code repository...Gai has already set up a Sourceforge page along with the requisite SVN repo although only he has access to do updates. Any changes would need to be forwarded as diff files to him for upload. I'll email him asking for other possible update methods. I'll ask him to set up a Beta branch if he's willing to so that 6.0.1.2 would remain as the base until a new version is ready.

The other issue is getting quality coders on board, so we may have to limit access to those who are able to show familiarity with the codebase, C# in general and an ability to actually add value to the project. Maybe we'll run something like C# Survivor where you can get voted off

Feature sets...Once the code has been cleaned up, there is a lot of stuff in the 'todo' list to look at adding or updating so we'd most likely need some sort of issues register. I have no experience in using any of these, so if someone has a suggestion, please do.

Thoughts?

I'll be the first to admit that I don't follow all of the programming standard that is set out in the thread you linked too. Some of the code was made before the standards where settled, so I'm not really sure I could be held accountable for it. As far as verbose variable names, it's really something that people are going to have to swallow. It just makes the code much easier to read then a bunch of one letter variables. Variable name size does not make your compiled program any bigger, so I recommend not worrying about that, and worrying more about if you can read the code a year from now. It's also very helpful to have different classes of thing with the program typed in different ways. One example of this is variables are always preceded with a dolor sign in PHP, $. Functions could then there for use all camelCase, and classes could be CapitalCase, const and defines are always UPPERCASE.

Found this that covers most of it: http://weblogs.asp.net/lhunt/attachment/591275.ashx


Extract:

2.1 General Guidelines

1. Always use Camel Case or Pascal Case names.
   
2. Avoid ALL CAPS and all lowercase names. Single lowercase words or letters are acceptable.
   
3. Do not create declarations of the same type (namespace, class, method, property, field, or parameter) and
   access modifier (protected, public, private, internal) that vary only by capitalization.
   
4. Do not use names that begin with a numeric character.
   
5. Do add numeric suffixes to identifier names.
   
6. Always choose meaningful and specific names.
   
7. Always err on the side of verbosity not terseness.
   
8. Variables and Properties should describe an entity not the type or size.
   
9. Do not use Hungarian Notation! Example: strName or iCount
   
10. Avoid using abbreviations unless the full name is excessive.
    
11. Avoid abbreviations longer than 5 characters.
    
12. Any Abbreviations must be widely known and accepted.
    
13. Use uppercase for two-letter abbreviations, and Pascal Case for longer abbreviations.
    
14. Do not use C# reserved words as names.
    
15. Avoid naming conflicts with existing .NET Framework namespaces, or types.
    
16. Avoid adding redundant or meaningless prefixes and suffixes to identifiers. Example:
    // Bad!
    public enum ColorsEnum {…}
    public class CVehicle {…}
    public struct RectangleStruct {…}
    
17. Do not include the parent class name within a property name. Example: Customer.Name NOT Customer.CustomerName
    
18. Try to prefix Boolean variables and properties with “Can”, “Is” or “Has”.
    
19. Append computational qualifiers to variable names like Average, Count, Sum, Min, and Max where appropriate.
    
20. When defining a root namespace, use a Product, Company, or Developer Name as the root. Example: LanceHunt.StringUtilities
    

Hello Krayy,


You are now admin on sourceforge server, please leave me as admin

Have luck

Gai-Luron

Quote from Krayy :

Found this that covers most of it: http://weblogs.asp.net/lhunt/attachment/591275.ashx

That list of standards is pretty good.

Personally I'd suggest following the .NET Design Guidelines for Developing Class Libraries and the Microsoft Internal Coding Guidelines