Most commonly used naming conventions.

BlitzMax Forums/BlitzMax Programming/Most commonly used naming conventions.

Paul "Taiphoz"

(Posted 2007) [#1]

I was thinking about this today, its been ages since I coded anything major and as a result its a good time to re-evaluate the way I code.

So I was wondering what the most common naming conventions being used in Max are at the moment.

Examples speak a thousand words... ;)

rdodson41

(Posted 2007) [#2]

Heres what I do:

Types are in the form TThing such as TAlien or TColorRequester where the first letter of each 'word' within the name is capitalized.
Functions and Methods are in the form Update or GetPosition the same as Types without the preceding T.
Variables are in the form aliens or current_file where every letter is lowercase and 'words' are delimited by underscores.
Constants are the same as variables except letters are uppercase such as MODE_CLIENT or SHIP_MAX_SPEED.

Example:

Superstrict

Type TAlien
    Const SPEED:Int = 6
    Const HEALTH:Int = 10

    Global aliens:TList = CreateList()

    Field x:Int
    Field y:Int
    Field direction:Int

    Field velocity_x:Int = 0.0
    Field velocity_y:Int = 0.0

    Function Create:TAlien(x:Int, y:Int, direction:Int)
        Local alien:TAlien = new TAlien
        alien.x = x
        alien.y = y
        alien.direction = direction
        ListAddLast(aliens, alien)
        Return alien
    EndFunction

    Method Update()
        x :+ velocity_x
        y :+ velocity_y
    EndMethod

    Method GetSpeed:Int()
        Return Sqr(velocity_x * velocity_x + velocity_y * velocity_y)
    EndMethod
EndType

FlameDuck

(Posted 2007) [#3]

Our types are named in the fashion: <qualifier><type><name>, where qualifier is usually as or ww, Type is either 'C' for concrete class, A for abstract class or I for interface.

References to these are named <qualifier><type><name> where type is any capital letters in the class name.

Variables or references to other peoples objects use simple Hungarian notation.

Here is an example from our Logging module:

SuperStrict

'{module}

Import BRL.Stream
Import BRL.FileSystem
Import BRL.System
Import BRL.Retro
Import BRL.Blitz

Type asCLog
	Global aslMyInstance:asCLog
	Field tsOut:TStream
	Field iDebugLevel:Int = LEVEL_CRITICAL | LEVEL_INFO | LEVEL_DEBUG
	
	Const LEVEL_CRITICAL:Int = 1
	Const LEVEL_INFO:Int = 2
	Const LEVEL_DEBUG:Int = 3
	
	Function create(sFilePath:String)
		If aslMyInstance <> Null
			cleanup
		EndIf
		aslMyInstance = New asCLog
		If FileType ( sFilePath ) = 0
			CreateFile( sFilePath )
		EndIf
		aslMyInstance.tsOut = OpenFile( sFilePath )
		aslMyInstance.tsOut.seek(aslMyInstance.tsOut.size())
		aslMyInstance.info("*** Logging initiated ***")
	EndFunction
	
	Function getInstance:asCLog()
		If aslMyInstance = Null
			create("debug.log")
			OnEnd cleanup
		EndIf
		Return aslMyInstance
	EndFunction

	Method critical(sMessage:String)
		If iDebugLevel & LEVEL_CRITICAL
			write( "CRITICAL" , sMessage)
		EndIf
	EndMethod

	Method info(sMessage:String)
		If iDebugLevel & LEVEL_INFO
			write("INFO" , sMessage)
		EndIf
	EndMethod

	Method debug(sMessage:String)
		If iDebugLevel & LEVEL_DEBUG
			write("DEBUG" , sMessage)
		EndIf
	EndMethod

	Method write(sSeverity:String , sMessage:String)
		WriteLine(tsOut , LSet( sSeverity , 10) + CurrentDate()+" [" + CurrentTime() + "]  :  " + sMessage)
		FlushStream(tsOut)
	EndMethod

	Method close()
		CloseStream(tsOut)
	EndMethod
	
	Function cleanup()
		If asCLog.aslMyInstance <> Null
			asCLog.getInstance().info("*** Logging session ended ***")
			asCLog.getInstance().close
		EndIf
	EndFunction
EndType

CS_TBL

(Posted 2007) [#4]

types:
========

type definition: T+Typename
(e.g. TColor)

a wrapper function: Create + Typename
(e.g. CreateColor)

variables:
============

variables to define of a rect: x,y,w,h

a variable to define a parent: parent

variables for generic counters: t,t2,i,i2,j,x,y,z,c

variables for strings: s, st

variables for color: r,g,b, r1,g1,b1, r2,g2,b2, grey

variables for events: ev

function/method naming:
=========================

One capital per functional bit, unless there are typically capitals in a non-code-context.

So: Colorchooser, instead of ColorChooser, as color and chooser could be (functionality-wise) two different bits.
But also: 'RGB' as functional bit, e.g. UpdateRGB. Since RGB is often written in capitals.

in/out/set/get/update/etc. things for functions and methods: with a capital, including fields, so: UpdateColorchooser, GetColorchooserColor, ResetColorchooser etc.

Indenting:
============

Apart from the usual for/next, while/wend, if/endif things I also indent the code between a setbuffer and flip. Additionally I -tend to- indent things that aren't really a scope, but do belong to something. For example, I indent the creation of menus for a menugadget, I indent filling a just declared array etc.

Paul "Taiphoz"

(Posted 2007) [#5]

Yeah that's close to what I use now, although I tend not to underline variables.

I was thinking of changing to a 3 letter prefix, kinda like file extentions.. but not sure if its OTT or not.


Const Con_NAME
Int : Int_Number
String : Str_Name
Float : Flt_LongNumber
Double : Dbl_ReallyLong
Function HelloWorld() : Fnc_HelloWorld()
Method HelloWorld() : Mth_HelloWorld()
Type Bullet : Typ_Bullet
Global Var : Glb_Str_PlayerName etc....

Not sure tho, I did a quick find and replace on some code and tried it like the above and also like file extentions at the end and both actually look ok.

Scaremonger

(Posted 2007) [#6]

I use CAPITALS for constants and prefix types with T and a derivative of Hungarian notation for most variables:
n = Int (Number)
s = String
l = Logical/Boolean (Even though they are still an int)
a = array (as for array of string, an for Array of number)...
etc.

I do not use hungarian notation for field variables if they are public properties; but instead make them SentenceCase. Variables who's type is a user defined "Type", are all lowercase...

  Local client:Tclient
  Local aliens:Tlist

The only single letter variable I use (and do not adhere to hungarian notation) are x,y,w,h and colours r,g,b.

I use CamelCase for all multipart names and only ever use an underscore in a constant. All functions start with a Capital, and Methods start with a lowercase character.

In all type constructor functions I create variables called "me".

'############################################################
Type Texample
  Field name:String
  '------------------------------------------------------------
  '# Create an example
  Function Create:Texample( sName:String )
  Local me:Texample = New TExample
    me.name = sName
  Return me
  End Function
End Type

Local variable declaration and return values are indented to the depth of the function, but the function body is indented one deeper (see code above).

I do not indent "Case" statements; I split them with a 40 character comment as follows (Notice the comment on each case too)...

Select EventID()
'----------------------------------------
Case EVENT_APPSUSPEND			'# App has lost focus
  '# Code indented
'----------------------------------------
Case EVENT_APPRESUME			'# Not used
  '# Code indented
'----------------------------------------
Case EVENT_APPTERMINATE			'# This is processed in updateGameState()
  '# Code indented
'----------------------------------------
Case EVENT_KEYDOWN			'# Not used
  '# Code indented
'----------------------------------------
end select

I seperate methods/functions within a type with a 60 character comment of hyphens, and seperate blocks (variable declaration, game loop, Functions, types, with a 60 character comment of hashes.

There are probably a million ways of coding. The best ways are those that make the code more readable. Not the ones that try to abbrieviate everything. (Why is abbrieviate such a long word)..!

tonyg

(Posted 2007) [#7]

Why is abbrieviate such a long word

I can make it about 11% shorter for you :)
When I can be fussed I use the same as Rich_d.

grable

(Posted 2007) [#8]

' types are camel case with a prefixed T, also note the order of declarations.
Type TIntStack
	' constants are upper case with underscores
	Const MAX_SIZE:Int = 10
	
	' globals & fields are camel case
	Field Items:Int[]
	Field Pos:Int

	' functions & methods are camel case, parameters are lowercase
	Method PushValue( value:Int)
		' locals are lowercase
		Local tmp:Int
	EndMethod
EndType


' toplevel globals are camel case
Global TestValue:Int = 1

' top leve locals are lower case
Local stack:TIntStack = TIntStack.Create()

' space to seperates logical parameters
LoadAnimImage( "file", 32,32, 0,10)

I allso use tabs at each new level, and spaces between operands in expressions.

EDIT: This is for basic/pascal like languages, but for C like languages i use mostly upper case for structs and defines, and lower case with underscores for everything else.

ImaginaryHuman

(Posted 2007) [#9]

I find that simple names are good but they should be meaningful enough. I generally use Count for loop counters, also Count2, Count3 etc, unless using X or Y or whatever is more meaningful. I don't use underscores much, or uppercase except to capitalize the first letter of each word. I think if you have to go with really long names then you are asking for trouble because it implies that your design and layout are too nested and too hierarchical.