Difference between revisions of "User:Void Singer/Formating"

From Second Life Wiki
Jump to navigation Jump to search
m (cleanup)
Line 2: Line 2:
== Coding Practices: Formatting ==
== Coding Practices: Formatting ==
<div style="padding: 0.5em">
<div style="padding: 0.5em">
this is a listing of how I format code, for readability and self documentation, not everyone likes it, but if you use something and stick with it, others will thank you, and you'll thank yourself later when you look at it and your eyes want to glaze over thinking "WTF was I doing?"
this is a listing of how I generally format code, for readability and self documentation, not everyone likes it, but if you use something and stick with it, others will thank you, and you'll thank yourself later when you look at it and your eyes want to glaze over thinking "WTF was I doing?" You definately don't have to format yours the same way. This is just here to share.
#variables:
#variables:
#* all user variables are prefixed with "v" (for variable) [so we can quickly Id variables]
#* all user local variables are prefixed with "v" (for variable) [to quickly Id variables]
#* all variables have their type included in 3 letters (eg. vStrData) [so we know the type, saves debugging typcast problems]
#* all variables have their type included in 3 letters (eg. vStrData) [so I know the type, saves debugging typcast problems]
#* all variables denote what they are for (eg. key vKeyOwner = llGetOwner();) [saves on comments, makes it esay to know what we're doing]
#* all variables denote what they are for (eg. key vKeyOwner = llGetOwner();) [saves on comments, makes it esay to know what I'm doing]
#* all States prefixed "vs" -eg vsStateName [so we can id states]
#* all States prefixed "s" -eg sStateName [to id states]
#* all user defined functions prefixed "vf" and return type -eg vfFunctionName [so we can Id functions and their return types]
#* all user defined functions prefixed "u" and 3 letter return type -eg uFunctionName [to Id functions and return types]
#* All Globals are prefixed with "vg" (for variable-global) [makes it easy to spot globals]
#* All Globals are prefixed with "g" [to spot globals]
#* All Constants are prefixed "c" and placed in all caps to distinguish from ll -eg cSTR_TITLE [easier to spot non ll constants, and avoid possible conflicts with new ll constants]
#* User Functions, User States, and variables use CamelBack style (capitized words, no spaces/underscores)
#* Bitmasks and booleans are given type "vBit" and "vBoo" [so we know how they are being used]
#* All Constants are prefixed "c", use all Caps, and underscores -eg cSTR_TITLE [spot non-LSL constants, avoid conflicts with new LSL constants]
#* Bitmasks and booleans are given type "vBit" and "vBoo" [to know how they are being used]
#* Vectors describing Size, Position, or Color are given as vSiz, vPos, & vCol, respectively
#* Vectors describing Size, Position, or Color are given as vSiz, vPos, & vCol, respectively
#Comments: [use lots of them to help us remember/see what code is trying to do]
#Comments: [use lots of them to remember/see what code is trying to do]
#*Sections/Headers: "//--// text //--//"
#* Sections/Headers: "//--// text //--//"
#*Code: " //-- the line below does X" (note the extra space indent
#* Code: " //-- the line below does X" (note the extra space indent)
#*Edit/Notes: " //-- the line to the left is editable or could use changes"
#* Edit/Notes: " //-- the line to the left is editable or could use changes"  
#Brackets/Whitespace:
#Braces, brackets, and parentheses:
#*Functions: space away from the container -eg. llRound( vIntNumber ); [makes it different from grouping]
#* Functions: space away from the container -eg. llRound( vIntNumber ); [makes it different from grouping]
#*math: always separate math -eg 2 + 2, exception increments --x, ++x [easier to read/debug]
#* math: always separate math -eg 2 + 2, exception increments --x, ++x [easier to read/debug, prevent unary operator errors]
#*Grouping: do not space inside, or out -eg. ((vIntNumber + 2) * 5) [makes it different from functions]
#* Grouping: do not space inside, or out -eg. ((vIntNumber + 2) * 5) [makes it different from functions]
#*Events: follow function rules + { -eg. touch_start( integer vIntTouches ){
#* Events: follow function rules -eg. touch_start( integer vIntTouches ){
#*If/Loop: follows grouping rules with a space before group, and trailing { -eg if (TRUE){
#* If/Loop/while: follows grouping rules with a space before group -eg if (TRUE){
#*loops, if/else, events, states, functions: "{" goes on the same line as the calling body, "}" after the last entry, and are ALWAYS used (even where optional) [for readability & debugging]
#* All control structures, states, user functions: "{" goes on the same line as the calling body, "}" after the last entry, and are ALWAYS used [readability, debugging, code insertion safty]
Note:
#WhiteSpace:
Due to disagreement about placing "{" on the same line as the originating structure, they
#* blank line between event [groups event code]
will be on the line following the structure for WIKI function examples... it's a matter of
#* blank line between sections of code doing different things [groups similar actions]
personal taste and practice for me, so not a big deal =)
#* tabs are set at 2 spaces, [reduce wrapping of nested items]
#General WhiteSpace:
#* All items inside a control structure, state, or user function are indented one level [eaiser to read/debug]
#*blank line between event [easier to read]
#Special Items:
#*blank line between sections of code doing different things [groups like actions]
#* Bitmasks, Keys, and hexadecimal codes are in uppercase -eg. 0xFFFFFFFF [to see usage, readability]
#*tabs are 2 spaces, to reduce wrapping for nested items. any items inside a loop, if/else, event, state, or function recieves a tab [saves wrapping, eaiser to read/debug]
#* Long tests/function calls: wrap each variable/container to the next line with level spacing -eg see below [readability, cleaner than built in wrapping]
#Special Cases:
<lsl>
#* Bitmasks given as numbers are in uppercase hex -eg. 0xFFFFFFFF [easier to see usage]
#* Long tests/function calls: wrap each variable/container to the next line with level spacing -eg see below [easier to read, less sloppy than built in wrapping]
<pre>
//--// this is an example script    //--//
//--// this is an example script    //--//
//--// it has no real purpose other //--//
//--// it has no real purpose other //--//
//--// than to show my formatting  //--//
//--// than to show my formatting  //--//


string  cSTR_TITLE = "example script" //-- something to tell the user later
string  cSTR_TITLE = "example script:"; //-- something to tell the user later
integer  vgIntTotalTouches = 0;
integer  gIntTotalTouches = 0;


string vfStrFunctionExample( key vKeyOwner ){
string uStrKey2Name( key vKeyAvatar ){
   return llKey2Name( vKeyOwner );
   return llKey2Name( vKeyAvatar );
}
}


default{
default{
   state_entry(){
   state_entry(){
     llOwnerSay( "Hi, " + vfStrFunctionExample( llGetOwner() ) );
     llOwnerSay( "Hi, " + uStrKey2Name( llGetOwner() ) );
   }
   }


Line 56: Line 54:
       //-- below is the example of wrapping functions parameters
       //-- below is the example of wrapping functions parameters
       llSay( 0,
       llSay( 0,
             cSTR_TITLE + " has been touched "          //-- this is an example of
             cSTR_TITLE + " has been touched "          //-- this is an example of my
                         + (string)(++vgIntTotalTouches)  //-- string wrapping, always
                         + (string)(++vgIntTotalTouches)  //-- function wrapping, lines start
                         + " times" );                    //-- has + in the front
                         + " times" );                    //-- with math/join symbols when avalable
     }while (--vIntTouchCount > -1);
     }while (--vIntTouchCount);
   }
   }


   changed( integer vBitChanged ){
   changed( integer vBitChanged ){
     if (vBitChanged & CHANGED_OWNER){
     if (CHANGED_OWNER & vBitChanged){ //-- variables on the right in tests
       state vsReset
       state sReset;
     }
     }
   }
   }
}
}


state vsReset{
state sReset{
   state_entry(){
   state_entry(){
     llSay( 0, "New Owner " + vfStrFunctionExample( llGetOwner() ) + " detected; reseting" );
     llSay( 0, "New Owner " + uStrKey2Name( llGetOwner() ) + " detected; reseting" );
     llResetScript();
     llResetScript();
   }
   }
}
}
</pre>
</lsl>
</div></div>
</div></div>


<div id="box">
<div id="box">
== Comments ==
== Comments ==
<div style="padding: 0.5em">
<div style="padding: 0.5em">
Feel free to leave me a note on my [[User_talk:Void_Singer|User Talk]] page.
Feel free to leave me a note on my [[User_talk:Void_Singer|User Talk]] page.
</div></div>
</div></div>

Revision as of 16:57, 31 March 2009

Coding Practices: Formatting

this is a listing of how I generally format code, for readability and self documentation, not everyone likes it, but if you use something and stick with it, others will thank you, and you'll thank yourself later when you look at it and your eyes want to glaze over thinking "WTF was I doing?" You definately don't have to format yours the same way. This is just here to share.

  1. variables:
    • all user local variables are prefixed with "v" (for variable) [to quickly Id variables]
    • all variables have their type included in 3 letters (eg. vStrData) [so I know the type, saves debugging typcast problems]
    • all variables denote what they are for (eg. key vKeyOwner = llGetOwner();) [saves on comments, makes it esay to know what I'm doing]
    • all States prefixed "s" -eg sStateName [to id states]
    • all user defined functions prefixed "u" and 3 letter return type -eg uFunctionName [to Id functions and return types]
    • All Globals are prefixed with "g" [to spot globals]
    • User Functions, User States, and variables use CamelBack style (capitized words, no spaces/underscores)
    • All Constants are prefixed "c", use all Caps, and underscores -eg cSTR_TITLE [spot non-LSL constants, avoid conflicts with new LSL constants]
    • Bitmasks and booleans are given type "vBit" and "vBoo" [to know how they are being used]
    • Vectors describing Size, Position, or Color are given as vSiz, vPos, & vCol, respectively
  2. Comments: [use lots of them to remember/see what code is trying to do]
    • Sections/Headers: "//--// text //--//"
    • Code: " //-- the line below does X" (note the extra space indent)
    • Edit/Notes: " //-- the line to the left is editable or could use changes"
  3. Braces, brackets, and parentheses:
    • Functions: space away from the container -eg. llRound( vIntNumber ); [makes it different from grouping]
    • math: always separate math -eg 2 + 2, exception increments --x, ++x [easier to read/debug, prevent unary operator errors]
    • Grouping: do not space inside, or out -eg. ((vIntNumber + 2) * 5) [makes it different from functions]
    • Events: follow function rules -eg. touch_start( integer vIntTouches ){
    • If/Loop/while: follows grouping rules with a space before group -eg if (TRUE){
    • All control structures, states, user functions: "{" goes on the same line as the calling body, "}" after the last entry, and are ALWAYS used [readability, debugging, code insertion safty]
  4. WhiteSpace:
    • blank line between event [groups event code]
    • blank line between sections of code doing different things [groups similar actions]
    • tabs are set at 2 spaces, [reduce wrapping of nested items]
    • All items inside a control structure, state, or user function are indented one level [eaiser to read/debug]
  5. Special Items:
    • Bitmasks, Keys, and hexadecimal codes are in uppercase -eg. 0xFFFFFFFF [to see usage, readability]
    • Long tests/function calls: wrap each variable/container to the next line with level spacing -eg see below [readability, cleaner than built in wrapping]

<lsl> //--// this is an example script //--// //--// it has no real purpose other //--// //--// than to show my formatting //--//

string cSTR_TITLE = "example script:"; //-- something to tell the user later integer gIntTotalTouches = 0;

string uStrKey2Name( key vKeyAvatar ){

 return llKey2Name( vKeyAvatar );

}

default{

 state_entry(){
   llOwnerSay( "Hi, " + uStrKey2Name( llGetOwner() ) );
 }
 touch_start( integer vIntTouchCount ){
   do{
      //-- below is the example of wrapping functions parameters
     llSay( 0,
            cSTR_TITLE + " has been touched "           //-- this is an example of my
                       + (string)(++vgIntTotalTouches)  //-- function wrapping, lines start
                       + " times" );                    //-- with math/join symbols when avalable
   }while (--vIntTouchCount);
 }
 changed( integer vBitChanged ){
   if (CHANGED_OWNER & vBitChanged){ //-- variables on the right in tests
     state sReset;
   }
 }

}

state sReset{

 state_entry(){
   llSay( 0, "New Owner " + uStrKey2Name( llGetOwner() ) + " detected; reseting" );
   llResetScript();
 }

} </lsl>

Comments

Feel free to leave me a note on my User Talk page.