Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / Coding Style Weirdness?

Author
Message
Mr909
14
Years of Service
User Offline
Joined: 2nd Jun 2012
Location:
Posted: 30th Oct 2012 19:29
Link
I think it would be nice to have some actual discussion that's not problem-solution based around here, and I've come up with an interesting question:
How weird am I?
For those of you who've seen my code, you'll notice I always all-caps my standard DB functions, leave my custom types/functions lowercase, use underscores in function names, as well as a few other stylistic things that, I'd imagine, tend to stand out.

I saw a tutorial before where the designer always put the first letters of his DB functions capital, like proper names.

Does anybody else want to confess to a weird coding style? Did you used to have one, but grew out of it? Do any particular methods bother you?

Just thought it would be an interesting coding discussion. Feel free to contribute.
Back to top
Profile PM Email
basjak
16
Years of Service
User Offline
Joined: 16th Apr 2010
Location: feel like signing up for mars
Posted: 30th Oct 2012 20:49
Link
although you didn't get much response for your question but I cannot deny the importance of it.

DBpro editor does not recognize capital from lower case letter when it comes to functions.

however, it is good programming practice to do so. as it will make your code more readable.

many of the C++ programming community follow microsoft msdn programming style by adding '_' before any function or variable name, to tell the code reader that it is the start of a new function name or variable.

I don't know how big your programs are but once you get to the level where your code end up with plenty of function and variables, you will find yourself automatically gone into capitalizing to manage to read your own code.

Back to top
Profile PM Email Website
Sergey K
22
Years of Service
User Offline
Joined: 4th Jan 2004
Location:
Posted: 30th Oct 2012 20:50 Edited at: 30th Oct 2012 20:52
Link
its highly suggested to work with correct style so you can read it easy, and ppl will understand your code easier.
more sorted game = less bugs

just like my style in bottom of this reply, its much easyer to understand it for everyone..

my style:


Advanced Updater for your games!
Back to top
Profile PM Website
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 30th Oct 2012 22:42
Link
@Sergey K

Why not "endFunction" as well?

I agree with you that "camel case" aids readability. Probably more important though is careful indenting of code (as in your example). That makes the structure much easier to follow - unless the blocks are so long you can't see where they start and end at the same time.
Back to top
Profile PM Email
Phaelax
DBPro Master
23
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 31st Oct 2012 02:44
Link
What you're describing is known as "coding conventions", and it can be different in every language. No formal convention has ever really been defined for DBP, so I tend to take a Java approach(which many languages look similar). Which is typically what people refer to as "camel case". In java, you start with lowercase. In C# you'll find the majority start with uppercase.

Indentation is very important, and every nested block should be indented inside its parent.

I'm not as strict with my own rules in DB as I would be in another language. But most other languages are case-sensitive. And if you ever have to do Cobol, ohhh boy you better indent properly or the code won't even work!

Quote: "you'll notice I always all-caps my standard DB functions"

All caps are generally regarded as constants. For me, when I use globals in DBP I'll either make them all caps too or use camel-case starting with upper.

All this may not sound like a huge deal when working alone, but when you have to start sharing code with others or finding stuff on the web to look at, you'll be happy if everyone uses the same conventions.

"You're not going crazy. You're going sane in a crazy world!" ~Tick
Back to top
Profile PM Email Website
Ortu
DBPro Master
18
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 31st Oct 2012 03:10
Link
I'll all caps constants and globals using _ in complex names to break up words. camel case my functions and variables starting with lowercase and no _s

Built in dbp functions I just leave all lower case as the editor will color code them to set them easily apart

Back to top
Profile PM Email Website
Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 1st Nov 2012 10:32
Link
For the standard DB functions, I don't even worry about capitalization. It's already highlighted a different color in my IDE, and any convention goes out the window since there are spaces in the function names.

I usually tend to stick to all lower case for variables, underscores for constants, camelCase for functions/subroutines, aaaaand for globals I add specific prefixes depending on what module they're in. (core_, hud_, etc)

It's never been a problem for me, but then again most of my projects are small.

Back to top
Profile PM Email
Kezzla
17
Years of Service
User Offline
Joined: 21st Aug 2008
Location: Where beer does flow and men chunder
Posted: 1st Nov 2012 20:52
Link
I usually code in lowercase, have a tendency to have variable names that are almost_complete_sentences_separated_by_underscores.

//====================================================================
I break my code up into lots of routines and place them in sections in my dbp files,I use rem asci borders to contain them.
//====================================================================


My debug functions tend to have random insulting messages that relate very little to the problem being solved.

if I cannot fix a bug for an extended period of time and I am getting tired I will tend to express my frustration via a slightly homicidal if statement somewhere near the offending block.

i tend to keep the old versions of routines commented out where they originally were for reference and just in case.

about all I can think of

Back to top
Profile PM
Libervurto
20
Years of Service
User Offline
Joined: 30th Jun 2006
Location: On Toast
Posted: 4th Nov 2012 10:24 Edited at: 4th Nov 2012 10:26
Link
The way I split up the initialization from the main loop has gone through a lot of style changes.

The last one is what I use now. I think it's subtle but also clear. I like marking this boundary because the two areas work very differently. I also do the same for subroutines and functions.

I type everything lower-case, except for comments, which I write out in proper sentences.

Oh something else I do is at the end of every function and subroutine:

I just find it distinguishes them nicely.

Shh... you're pretty.
Back to top
Profile PM Email
Mr909
14
Years of Service
User Offline
Joined: 2nd Jun 2012
Location:
Posted: 5th Nov 2012 23:09
Link
@OBese87: Heh, I like the "evolution of the header".

I think my //////// originated from reading Walkthroughs on GameFAQs that used it to distinguish headers.

@Kezzla: You're awesome, Kezzla Your debug messages remind me of my test inputs; I'll come up with the stupidest, random strings just to prove it's printing/replacing the string/whatever properly. One of my old "Hello World" tests, back when I was learning to program, was "THE MENACE COMETH" over and over again

@Neuro: Global variable distinction based on modules sounds like an interesting and quite valuable system. Thanks for the tip.

Why does nobody use shouty capitals like I do for my DarkBASIC functions? I always thought it helped it read clearer. Guess that's just me being me, though.
Back to top
Profile PM Email
Back to top

Login to post a reply

Server time is: 2026-07-12 17:59:13
Your offset time is: 2026-07-12 17:59:13