Programming Styles

[lua]

_____________________variable = 0;;;;; // Sets _____________________variable to be equal to 0 – Johnny Guitar

local function _____HolyShit(__dicks, dick);; // Create a new function that accepts a local variable __dicks and a global variable dick – Johnny Guitar
end;;;

[/lua]

[lua]
local function CreateSomeInfo( pl )
pl.PlayerInfo = pl.PlayerInfo or {}
pl.PlayerInfo[ “somekey” ] = true

	-- Comments are indented
if pl.PlayerInfo[ "somekey" ] then pl:ChatPrint( "You have the key!" ) end

pl:NetworkInfo()

--[[while true do
	print("test")
end]]

end
[/lua]

Also I never use ~=, only !=

Word of warning: Never ever use /* */
This is handled by Garry’s preprocessor and beaks line numbering.
Try running this in a file:



/*
a
a
a
*/
error"hi"


Oh god, debugging DarkRP jobs.lua and shipments.lua is such fun with the comments on top of the file :v: All these kids coming to Facepunch: “I don’t see the error on line …!”.

Overall is:




[type][get/set][CamelCase(Function/Method)Name]
[type][CamelCase(Variable/Class/Struct)Name]

//LUA

local tTableOfContents = {
            sTitleName     = "It",
            sAuthorName  = "Stephen King",
            iPagesCount   = 500
};

if(isSomething(oThing) and (true == bVar)) then --Got this Doing alot of C++ xD
   oEnt:SetPos(); -- For Gmod realted methods
end

// C, C++, AnsiC

typedef class Vector {
             private:
                double X;  // .... and so on
             public:
              class Vec& getNormalized();  
              class Vec& Normalize();
                    double getAbs();
              friend Vector operator+(Vector, Vector);
}  cVec;

// Pro*C

EXEC SQL SELECT //some stuff here
                  INTO :sTableName
                  FROM TableName
                WHERE Condition;



I hate my life.

  1. Lower camelCase for locals/parameters

  2. Upper CamelCase for everything else

  3. No semicolons

  4. Always use verbose operators, e.g: not, and, or

  5. Spaces after commas and delimiters unless no arguments/key-values are passed, e.g:
    [lua]
    func1( a, b, c )
    func2()

local tbl1 = { a, b, c }
local tbl2 = {}
[/lua]

  1. Document everything

Example:
[lua]
— All functions are available also as methods of the complex number class.
– Operators work with both numbers and complex numbers.
@author Pac
@classmod complex

local complex = {}
complex.__index = complex
complex.__newindex = function() error( “attempt to index complex value” ) end

— Constructors
@section Constructors

— Creates a new complex number
@tparam[opt=0] number real
@tparam[opt=0] number imag
@treturn complex
@usage local c = complex.New( 1, 1 )
function complex.New( real, imag )
local obj = {}

obj.Real = real or 0
obj.Imag = imag or 0

setmetatable( obj, complex )
return obj

end

— Fields
@section Fields

— Real part
complex.Real = 0

— Imaginary part
complex.Imag = 0

— Functions
@section Functions

— Returns whether the given complex numbers are equal
@tparam complex c1
@tparam complex c2
@treturn bool
function complex.Equal( c1, c2 )
return c1.Real == c2.Real and c1.Imag == c2.Imag
end

— Returns the sum of the given complex numbers
@tparam complex c1
@tparam complex c2
@treturn complex
function complex.Add( c1, c2 )
local real = c1.Real + c2.Real
local imag = c1.Imag + c2.Imag
return complex.New( real, imag )
end

— Returns the difference of the given complex numbers
@tparam complex c1
@tparam complex c2
@treturn complex
function complex.Sub( c1, c2 )
local real = c1.Real - c2.Real
local imag = c1.Imag - c2.Imag
return complex.New( real, imag )
end
[/lua]

Dude you got more comments than code there

But it’s so pretty :suicide:

[editline]21st May 2014[/editline]

I only really use LDoc commenting in modules like this that I use tons of places and even share with select people. It doesn’t take long either, it’s primarily a copy-paste job.

I don’t know about you guys, but I don’t always find it necessary to comment and document certain things if to me they’re self explanatory.

Also I always write code assuming that it will always be used properly, so I don’t usually do null checking or anything unless I know it’s possible for something to be null. Like handling entities.

I personally like the following style:

lowerCamelCase for variable names
UpperCamelCase for function names
_lowerCamelCase for implementation variables that shouldn’t be modified (eg something that you should use a getter or a setter on a meta table to access)

CAPS_WITH_UNDERSCORES for constants (well variables that I never change… so as close as you can get for constants)

All that really matters is this: MAKE SURE YOU HAVE A FORMAT
It doesn’t really matter what your format is (though if it’s mine it’s the right one <3) but make sure you have one and make sure it allows you to tell what purpose a variable plays without having to find where the variable is assigned. You should be able to look at a variable and say oh that’s a value or oh that’s a function.
You should also have naming rules like all functions that check something and return a boolean are prefixed with Is eg: IsMyFormatCool( format )? or for something that inits an object always start with Init or Make or Setup but ALWAYS USE THE SAME THING don’t switch around throughout your code.
For methods that are internal make sure you denote that with how you name them. Use an _ or something like that to suggest that yes, you can see this and it is exposed, but really it’s not something you’re ment to call or i woulda made the name more natural.

Just use consistant naming so when someone else takes a look at your code they can figure out what your rules are and can make sense of your code.

(I only write such a long rant because right now I’m helping a friend who’s trying to fix up a project written entirely in E2 capitalized format)

EDIT: EvacX and I use exactly the same formatting rules apparently :slight_smile:

Well yeah, but you’re missing the point. I write my code as if someone else has to use it, and sometimes that’s even the case. The generated documentation is an easy way to look-up which functions are available to you and it helps expressing the bigger picture.

If you look at my example, sure, it’s all fairly self-explanatory, it’s a math library after all. The shown documentation is not nearly as beneficial as it can be in other situations. I just chose that exact example because it didn’t require any prior knowledge to understand what was going on, it’s just math.

Oh, and the generated pages look cool.

Since I’m using simploo a lot nowadays I had to force myself to a consistent coding style otherwise things would have gotten messy.
You should be able to figure it out for yourself by looking at it.
gist

(semi colons are there because simploo uses tables, so I could also use things like commas, but semi colons seemed more appropriate. I don’t use them in code that doesn’t require them)

I like spaces



-- This function handles players opening crates.
function TGC.HandlePlayerOpening( ply, crate )

	if ( not ply:IsPlayer() ) or ( not ply:Alive() ) or ( not IsValid( crate ) ) then return end
	
	local timerName = tostring(ply) .. tostring(crate);
	local endTime = CurTime() + TGC.UncratingTime;
	
	if ( timer.Exists( timerName ) ) then return end
	
	-- Freeze, send and create a timer.
	ply:Freeze( true );
	TGC.SendCrateTime( ply, CurTime(), endTime );
	timer.Create( timerName, TGC.UncratingTime, 1, function()
		
		if ( not IsValid( ply ) ) then return end	-- Check for validity of player.
		
		ply:Freeze( false );	-- Unfreeze the player PLEASE.
		TGC.HandleUncrating( ply, crate );
		
	end )

end


Didn’t seem to break numbering for me…

[ERROR] lua/autorun/syntaxTest.lua:6: hi

  1. error - [C]:-1
  2. unknown - lua/autorun/syntaxTest.lua:6


/*
a
a

a
*/
error"test"


Edit: Turns out the issue is when a blank line is within the multi-line c-style comment.

I like semicolons.

Fight me.

Ever since I got into gLua I always forget to put semicolons in my PHP scripts. Fuck you Lua.