ID:1384902
 

Poll: Follow BYOND Conventions?

Yes 57% (15)
No 42% (11)

Login to vote.

When writing DM (especially for public code), would it be better to conform to the built-in code conventions that the BYOND engine provides or to stick with personal preference likely gained from learning other languages?

BYOND's (apparent) style:
Types: some_type
Variables: some_variable, SOME_CONSTANT
Procs: global_proc(A, B, C), DatumProc(A, B = 2, C = "blah")

On one hand, your code fits in with the stuff that everyone who uses DM has already learned (ha ha) and has to work with.

On the other, you (the writer) get to use a style that you think is "best" or "more common" in the "real world."
It doesn't matter. In general you should try to remain consistent though.
I think of "style" more as how things are spaced/organized/commented. Creating procedures with names like balllocation() isn't a style, it's just hard as hell to read and type!
When in Rome, do as the Romans do.

Unless Rome is the Win32 API, then don't.
I used to use lower_case for absolutely everything everywhere. When Forum_account released all his libraries and articles using that style, I stuck with it even more. But then, I actually thought about it. Now I do as the Romans do. I follow the style of the engine as closely as I can, and it's really easy to do since it's just going from mixing two styles to using only one.
I prefer to use my own style. In the industry using one's own style is not preferred, as it is better to conform with the platform's own style. But I don't work as a programmer. Things need to look aesthetically good for my own code.

EDIT: https://dl.dropboxusercontent.com/u/14221897/images/ makeii_code.png
I think that libraries or tutorials/snippets should be written to match the language's most prevalent style conventions, just so that the people who benefit from them the most can more easily pick up on what's what.

That said, though, I dislike BYOND's conventions, and I name everything "LikeThis". Everything. Vars, verbs, procs, atom types, etc.

CapitalizeEveryWordAndNoSpacesOrUnderscores

I especially hated BYOND's conventions back in the day when verbs and verb panels were the norm. I think having a box full of uncapitalized command names is just silly.
In response to SuperSaiyanGokuX
I think visible verbs should either be Upper_Case or be name-set to Upper Case. But then again, I use no visible verbs.
Oh, I guess I should clarify that point a bit, too. If I were to use any multiple-word verb names (like yourself, though, I do not use visible verbs), I would use an underscore in those names only, just so there's a space in the displayed name. (I hate "set name=[blah]"; just name the damn thing the way you want it to begin with! lol)
In response to Stephen001
Stephen001 wrote:
When in Rome, do as the Romans do.

Unless Rome is the Win32 API, then don't.

Ugh, hungarian notation...

Kaiochao wrote:
I think visible verbs should either be Upper_Case or be name-set to Upper Case.

I think verbs should be invisible at all times.
In general, I think it's better to stay close to the accepted "conventions", but you don't have to be too strict about it. You should just go with what works best for you, as long as you don't release libraries that are too extreme. If you find an easy and efficient way to write your code, and keep things well organized and commented, then everything should be fine.

This is basically how I write things:
obj
MySubtype
//////////////////////////////////////////////////////////////
// The following is how I usually name things. //
// I don't always stick to it though. //
// //
// Big descriptive comments get an outline like this. //
// It would usually be to mark the start of a large system, //
// and to summarize what it does. //
//////////////////////////////////////////////////////////////

// Usually, I will keep built-in vars and procs separate
// from the ones I define.
// However, if they are all part of the same system,
// then I will still keep them close.
icon = 'someicon.dmi'
icon_state = "somestate"
tag = "MySubtype"

New()
..()

Del()
..()
// Almost anywhere, whether it be in a type definition, or proc definition,
// I try to list the variables first,
// unless they must be initialized within a loop.
var
// For most object vars:
my_variable = "something"

// For more important or constant vars:
ImportantVariable = "something"

proc
// For procs that return values:
get_some_value(argument1, argument2)
var
// Temporary proc vars have very small names:
x1
y1

x2
y2

// For procs that do things:
DoSomethingImportant(argument1, argument2)

verb
// All verbs:
Run_This_Command(argument1 as this, argument2 as that)

In general, I keep less significant, or "generic" things lowercase, while I capitalize things that are more important.

No naming convention is perfect, but some are worse than others.

What I hate the most as a convention in DM are BIG_SCARY_CONSTANTS_THAT_ARE_JUST_OVERKILL. Are you serious? Do I really have to turn on Caps Lock, and then separate everything with underscores, just to write some silly constant?

Another thing that I really can't stand is when somebody who is stuck with the conventions of another language, decides to write DM code in the same way. For example, I never want to see nice clean DM code with a bunch of useless, distracting braces or semicolons tacked onto every single line!
please() {
stop();
{
doing();
THIS();
}
}

This is why I'm thankful we have languages like Python and Ruby, to help prove the existence of things like lines, tabs, and spaces, as if they were not enough to begin with.
I generally just use the Google C++ convention. Not all of it applies to BYOND, but the general ideas are still relevant.

http://google-styleguide.googlecode.com/svn/trunk/ cppguide.xml
I use conventions I've learned from .NET development, and use BYOND's conventions as a way to distinguish between 'Soft' code and 'Native' code.