ID:3178
 
If you've ever programmed in a group before, you'll understand how important naming conventions are. Without them, the code becomes inconsistent, and consequentially, hard to read. If you'll think about it for a second, you'll realize that DM has a set of naming conventions already set up for its built-in procs and variables. Obviously, if you make up your own set of naming conventions without regards to DM's, you'll end up with two different sets of naming conventions: yours and DM's. It won't be pretty. If you have two sets of naming conventions, you'd might as well not have any! Therefore, it's very important to know how DM names things. To find out, read this bwicki page!
I hate the DM naming conventions, so I just made myself a lib which makes them to my preference. =)
I've never liked the DM conventions of capitalization between procs and verbs...

To me, when verbs are displayed in the panels, they should be displayed with capital letters... It looks more proper that way...

And procs are hidden from sight, so they'd be fine with lower case letters...

DM's convention is the opposite of that, which I find to be extremely unintuitive...

However, I actually don't ever create any of them with lower case names, regardless of type... They all get capitals... I have never seen a need to differentiate them past having verbs indented under "verb" and procs indented under "proc"...lol
Obviously, if you make up your own set of naming conventions without regards to DM's, you'll end up with two different sets of naming conventions: yours and DM's. It won't be pretty. If you have two sets of naming conventions, you'd might as well not have any!

What you don't take into account here is that some of us program in more languages. Having a strong set of personal conventions helps you to write better code in all languages, because you don't have to think about the specific 'conventions' of the language you're writting in at the moment. As a general rule, I try not to write language specific code anyway.

Most of my projects define an interface for working with the built in procs in the DM language, and I store all of it in an 'interface.dm' file. This way, I'm working with my code the way I want to write it, and I don't have to wrestle with the built in aspects of DM everytime I want to change something.

What is especially annoying is the use of Capitalization in a language's built in api. Because capitalization is the source of so many confusions and errors, a strong system of case conventions is needed. My rule is to never use uppercase letters in anything. DM frustraits my quest for a case-less code with it's continued insistance on 'Client' and 'Move' and all sorts of other things that don't need capitalization but have it anyway. :sigh:

At least DM allows me to continue my use of semicolons and curly brakets. It is because of my consistant use of a set of conventions that I have been able to switch between languages quickly with little problems remembering the 'quirks' of each. I've even imported code I wrote in ECMAscript ages ago into a DM project I was writting.

To this end, I would suggest that it is more important to have your own naming system than to try and conform yourself to other people's conventions dependant on what language you're writting in. They called me crazy when I wrote my html element names in lowercase... now who's laughing!?!? Hm. Excuse the outburst.

Forsaking DM's suggested conventions may be the best thing for me, but I do regonize that it may not be the best thing for anyone else. My habitual use of brakets has prevented me from releasing libraries or working on projects with other programmers; I continually feel like I have to 'strip' my code of all that visual-structure before I send it to other users.
I try to observe DM's naming conventions in general (and in fact apply them to my Python scripts, because it's easier than trying to learn any naming conventions that may or may not apply in Python).

You might enjoy reading AmbySoft's Java Coding Standards. This (or, more likely, an earlier draft of it) was probably about the first thing that made me aware of the value of naming conventions.
I vastly prefer DM's naming conventions. Having been a Hungarian notary in C++, I quickly grew tired of that profession and emigrated. My Dreams were Made in Canada thanks to the diligent efforts of the Americans, and I now use a DM-like naming convention in every single language I use.

I'm going to have to buy a web domain and basic hosting package at some point, but until then I can still use my spuzzum.byond.com domain, so here's my own personal coding style. I actually wrote this out a few months ago, just in case I ever decided to open up my roguelike into the open-source (or invitation-source-with-background-check) community.

http://spuzzum.byond.com/misc/style.txt
Jtgibson wrote:
All braces start on the same line the block is opened, and end indented with the block...

I love you.

The same, however, is not true for functions and classes, whose braces appear in the more widely-adopted style...

-_- Then you go and break my heart.
All braces start on the same line the block is opened, and end
indented with the block:

=) When coding ActionScript I like to place the braces like that too. Otherwise everything gets too long and ugly.

In DM I use a sort of mixture between DM and AS's conventions, seeing as those are pretty much the only languages I know. :p

In DM, I'd do

mob
var awesomeness

instead of

mob
var/awesomeness

Also, I'd do something like:

mob
proc
initiateAwesomePower()

I can switch between not using braces and using braces easily. I find that often braces help, and at other times they don't. Because DM is so white-space-ationalised, it's easier not to use braces.
Also, whilst in DM since it doesn't matter how long variable names are (and stuff), I try to keep it explanatory and clear; but in AS the code isn't compiled so having long variable names slows down the program. =(
Just thought I'd mention that when I said "for functions and classes", I meant the very first block. The blocks which appear inside the functions (and classes, in D) all conform to the "first at end of line, last indented with block" system.

I'll stick an example function from my D project at the end of my style document. It's still at http://spuzzum.byond.com/misc/style.txt