Type / Class in-code name conventions / policy
Monkey Forums/Monkey Programming/Type / Class in-code name conventions / policy
| ||
| Hi guys, In BlitzMax we used to put a T before a type e.g. TSprite I know in monkey types are classes and seeing the examples from Monkey this is not common practice anymore to put for example CSprite but just Sprite. How do you feel about this? Any sugestions? Thanks! |
| ||
| I still use the 't' prefix. but it's all just a personal preference |
| ||
| Yep, but when writing a module or framework it's nice to know what people prefer. |
| ||
| I would just prefer Sprite. |
| ||
| I always used the T, what's the convention for classes in other languages ? |
| ||
| I think one of the ideas with making Monkey case sensitive, was to allow you to do away with the t prefix. tMyclass could now be Myclass (or MyClass ?) and then variables can start with small letters. |
| ||
| In Java the class convention is the name with a captial first letter, in the example for a sprite class, it would be just Sprite. For a enemy sprite class it would be EnemySprite. The issue with using this in Monkey, is that the internal commands(methods) use this convention for methods, so you wont know what is a class or a method by looking at the call. Here is a link for the Java conventions: http://www.oracle.com/technetwork/java/codeconventions-135099.html#367 |
| ||
| I use capital first letter for class names and all small for variable names. If the variable name is very long, then I add an underscore also, but with classes variable names don't get very long, so underscores are never needed. |
| ||
| This is what I think I will use with Monkey: Class: Class Sprite Variables: Field playerBat:Sprite Methods / functions: Method collisions:Void() Function rectsOverlap:Int(x0:Float, y0:Float, w0:Float, h0:Float, x2:Float, y2:Float, w2:Float, h2:Float) Consts: Const MAX_TILES% = 32 |
| ||
| Small first letter and caps in the middle are the worst way, it looks really annoying :) |
| ||
| Imho it is all personal taste. Use what fits the best and if you create something for other people, use the methods of how the official modules use their naming conventions. |
| ||
| In the official modules variables are all small, and class names, methods and functions are first character per word capital. That's the best style! |
| ||
| ^Yup that's the convention we've been using. |
| ||
| From the docs (Monkey Language Reference section): Monkey naming convention The standard Monkey modules use a simple naming convention: All-caps case (eg: 'ALLCAPS' ): Constants Pascal case (eg: 'PascalCase' ): Classes Globals Functions, methods and properties. Camel case (eg: 'camelCase' ): Fields Locals and function parameters You are of course free to use your own convention, but for the sake of consistency it is recommended that this convention be used for the public interface of any modules you create intended for use by the Monkey community. |
| ||
| Camel case should be forbidden by Texas laws! |
| ||
| Small first letter and caps in the middle are the worst way, it looks really annoying :) iHaveNoProblem withThatPersonally, thisontheotherhand isfarworse butalltoooftenseen |
| ||
| lowercase methods will make it impossible to diferenciate a property method from a regular field :D I would case them. |
| ||
| Given that I code Java every day, I think I'll be sticking with this: Constants: UPPER_CASE_WITH_UNDERSCORES Classes and keywords: TitleCase Fields, methods, functions, global and local variables: camelCase The only exception to method names is New since it is also a keyword. The main point of naming conventions is so that you can (theoretically) look at an identifier and have a pretty good idea of what it is. |
| ||
| make it impossible to diferenciate a property method from a regular field Thats why when calling a method you should use the brackets: thisIsAField thisIsAMethod() |
| ||
| I like lowercase for keywords, uppercase for constants, pascalcase for class and camelcase for all the rest. |
| ||
| I always used the T, what's the convention for classes in other languages ? Depends on the language. In Monkey the convention is much like Java (see: Monkey Language Reference -> Identifiers -> Monkey naming convention), that is no Hungarian notation. Personally I'm in favour of the change as it can really get out of hand some times. Besides any typesafe language doesn't really need it IMHO. |
| ||
| Playniax, I'm also building a Framework and being consistent is imo the most important thing. Here is my code standard, feel free to use :) Code standards can be a good way to improve your code quality, and since I in no way suggest this is the perfect way to code in Monkey, it is just one suggested way, I'm open for feedback! Website version Word Version * One thing I have changed in it, is that private variables can be lowerCased if they are 100% private and are not used in inheritance. EDIT - How to make links, appear like links? |
| ||
| Links: (a http://blah)Linkdescription(/a) Replace () with [] |
| ||
| Thanks for the feedback guys! I think I will go for about the same style as the Monkey modules but I dislike the camelCase (sorry Mark:) In our Ignition framework I start every function and type with an 'i' e.g. iCLS or iDrawImage or iTSprite for a type, just to make it clear that it's a framework part. I think at the end doesn't matter and like Tibit said, being consistent is the most important. I'm going to think out it. |
| ||
| I like the camelCase. It makes sense. We use it in our company as well (all this Java type stuff but with C++) |
   |