Recommended code convention for DM?

ID:1114955
 
Jan 6 2013, 4:38 am
What is the recommended or "generally agreed upon" coding convention in DM?

My two guesses would be Java per Oracle, or standard practice C.
Jan 6 2013, 8:40 am
 
// lower camelCase for variables
var/lowerCamelCase

//  lower camelCase for procedures
proc/getTotal(a, b)
    return a + b

//  procedure indenting, rather than on a new line:
proc
    foo()
        return 1
    bar()
        return 0

//  the same as above for variables
var
    foo
    bar

    //  I just recently discovered you can declare lists like this in DM, which is similar to the C/C++ style, with the exception of
    //  initializing elements with curly braces, but I'm sure that works with list() as well
    myList[0]
    myList[5] = list(1, 2, 3, 4, 5)


That's what I use, not sure about others.
Jan 6 2013, 9:50 am
There isn't one. Everyone pretty much uses their own convention, from some_proc, someProc, to using braces and semi-colons, to not doing so.

I personally follow Oracle's code conventions.
Jan 6 2013, 9:55 am
Unfortunately, there are no conventions set by the developers or 'gurus'. Though, (LordAndrew and) I were planning to write a guide discussing the different ways of formatting your code and the benefits of one way over others.
Jan 6 2013, 3:10 pm
I am a camelCaser. I'm a little more liberal with my whitespace than Magnum2k is in his example.
Jan 6 2013, 3:18 pm
I just prefer consistency as a sort of "code".
If I do one proc lowercase, i prefer to do them all that way, likewise if I capitalize the beginning of a var, I tend to capitalize the first letter of all vars.

Consistency can provide small hints where there really isn't any other type of pattern to pick up on.
Jan 6 2013, 3:24 pm
Everything I do is lowercase, variables, procedures, file names. I might want to change that as it seems camelCase is much more common.
Jan 6 2013, 3:47 pm
I do stuff in CamelCaps
Jan 6 2013, 3:49 pm
I mainly do everything in lowercase, I do however capitalize my procs just so they stand out a bit more from everything else.
Jan 6 2013, 4:11 pm
There is already a naming convention, sort of. All built-in methods are Pascal case (eg world.ClearMedal()) while global procs are usually lowercase with words separated by an underscore (step_to()). There are a bunch of exceptions, though: text manipulation procs (cmptext/cmptextEx), conversion procs (num2text), interface procs (winshow), and type procs (typesof, istype).
Jan 6 2013, 4:46 pm
Yep, the convention for BYOND's built-in procedures have been discussed, but, I'm pretty sure most (real) programmers would conform to lower camelCase.

Garthor wrote:
There are already good naming conventions: lowercase for functions, UpperCase for methods. That is: any proc belonging to an object is in UpperCase, whereas any proc that is global is in lowercase. Functions also must use underscores to separate words, because they don't use case to indicate where a new one begins. The 2 for the conversion functions is a bit iffy but at least is consistent among them.

Tom wrote:
Uppercase names are hard-coded procs. Lowercase ones are functions.
Jan 7 2013, 6:41 am
Some of my code conventions are less common. I don't really do anything too wonky with my source, though.
#define CONSTANTVARSINALLCAPS 10

var
   vars_in_lowercase_with_underscore
proc
   procsInCamelCase()
verb
   Verbs_Uppercase_With_Underscore()

I'm also a bit weird when it comes to whitespace. I keep works in progress very spaced out, but once I'm finished with it and satisfied, I condense everything down.
proc
   workInProgress()
      if(somevar == 30)
         return TRUE
      else
         somevar = 30
         return FALSE

   fihishedProc()
      if(somevar==30) return TRUE
      else
         somevar=30
         return FALSE

I also try not to use brackets and semicolons to keep the code from getting cluttered with unneeded characters. Though being a C++ guy, I catch myself doing it anyways :P
Jan 11 2013, 12:26 am
Using {} is pretty useful. :>
Jan 11 2013, 1:46 am (Edited by moderator on Jan 11 2013, 2:17 am)
 
/mob/proc/procedure()
    return

/mob/var/variable_name = 0

/mob/verb/say(msg as text)
    set name = "Say"
Jan 11 2013, 11:27 am
In response to Xerif
Your verb convention seems way too overdone for my tastes. You could easily make the verb's name be "Say" by capitalizing the "S" in the definition. Plus, capitalizing the definition makes verbs stand out more from procedures. All in all using Cap_Case for verbs is the way I tend to go.

I can go either lower_case or camelCase with procedures. It all depends on how I feel when I start. Once I choose one though, I stick with it. My variables are always lower_case.
Jan 11 2013, 1:04 pm
In case anyone is curious, mine is:

Start procedures or variables that aren't meant to be called or overridden by the user (or your self) with an underscore

library
    var/_loop_count = 0 //used by the library
    _loop()
        //don't call this or override this
        //internal library use, only!


For functions that provide something the user can use, start with a capital letter, and each subsequent word capitalized.

projectile
    proc/Fire()
    proc/OnCollide()


For variables intended to access within class, we use lower case separated by underscores

mob/var
    hp
    max_hp
    tmp/hp_image_overlay


And to the outside world, all of these variables have get and set functions, for maximum control of the values.

mob/proc
    GetHP()
        return hp
    SetHP(n)
        hp = max(0, min(n, max_hp))// 0 <- n -> max_hp


Optionally, tag _ref on the end of anything that will cause an object to persist, preventing garbage collection...

mob/var
    tmp/owner_ref //if this isn't null, this won't be deleted


For short mathematical or utility type functions, all lowercase with underscores

proc/get_speed_delay(n)
    return x * y / n


I try to keep indentation down to a minimum by using slashes whenever possible, and if something is simple, I like to keep it inline.

I'd say that's about it with me! Thanks to everyone for sharing your habits.