Sorry your browser is not supported!

DBPro Coding Standard

This topic has been raised before and, failed drastically. From what I remember it was through trying to encompass all developers to adopt a single unified coding style without knowing the context in which the code was to be used. IE. a single inflexible coding standard does not suit everybody - especially in a predominantly beginner-orientated language. As such I shall approach this topic treading lightly, I aim to write this from a neutral and unbiased viewpoint, but the whole topic should be taken with a pinch of salt - please think things through before stepping in to reply, taking consideration of both sides of the argument. I am hoping that this topic will serve its purpose as a well structured debate as to the pros and cons of having a coding standard, and what its introduction (if any) to the community would entail.

To begin with I think it would be useful to take a step back and take a look at some of the advantages and disadvantages of the current DBPro language.
Pros:
-Mature and (fairly) stable IDE
-Efficient rapid prototyping language
-Easily accessible to newcomers
-[Syntactically lax compiler] (Read: Flexible and forgiving compiler)
-Simplistic and logical syntax
-Expandability with third party libraries
-Sufficient number of data types


Cons:
-Poorly (for the most part) written documentation
-Inconsistent naming conventions across language
-[Syntactically lax compiler]
-Low portability to other languages
-Array of different coding styles leads to confusion when studied externally (common to all languages)
-Poor integration with third party libraries (due to lack of standard naming conventions)
-Inefficiently-long function names
-Character encoding (tabs) incompatibility between IDEs
-Lack of operators

It should be made very clear now that the majority of the disadvantages listed are not of great concern to casual users / beginners for the sole reason that they are not likely to stumble upon any of these issues until a point such that they are ready to move on to another more advanced language. But, for those that do wish to progress from DBPro onto such languages it is a relatively difficult process due to suddenly having compilers which are very strict, people who rely on the cleanliness and readability of your code, and the need to port the codebase to other languages and / or platforms. In short the lax coding standards of DBPro set you up in a very bad position to progress onwards. As such, collaborative projects done in DBPro are made infinitely more complex by the fact that each individual will have a different (not necessarily bad) style of coding - meaning that incompatibility manifests itself because the code will simply not work together in harmony as intended. For the individual it means that finding a foothold to progress from BASIC to industry-standard becomes a great challenge.

A coding standard would have many benefits as I shall now outline. DBPro is often used for prototyping, with the final project being developed in a lower-level language such as C or Java. While such languages have many syntactical differences, they are far more similar than the vast difference between BASIC and C. Thus porting the codebase of a project from BASIC to C becomes a monumental undertaking (almost a complete re-write is needed) - something which would not be necessary if the project were to be ported from C to Java. Ironically it is possible to code in a style which is fairly similar to C (or any other such language). The code sample bellow showcases the similarities:



The two examples listed are nearly identical, where the first was copied from the second and then the relevant changes made to get it to a state where it would compiled under C - the changes taking about 30 seconds or so. Compared to if our original code was like this:



Converting such code to C would be so inefficient it would be quicker to just rewrite it from scratch. The example also showcases perfectly how lax the compiler is: variables do not have to be defined before use, there are multiple ways to construct an if statement, an irregular number of spaces is used for tabbing than standard etc. etc. Having standards is key to maintaing bug-free and easily portable code.

One thing to note is that I used functions such as loadObject() as opposed to Load Object. This is both on the grounds of portability and consistent naming conventions - I would propose a wrapper to truncate all DBPro functions removing any spacing, adding brackets and in lowerCamelCase.


I do not want to overwhelm anyone so I think I shall cut my introduction there. But the point I would like to raise is the sheer usefulness of at least having some kind of standard in place:
-Portable code
-Improved maintainability and readability
-Simplifies transition to lower-level languages
-Instills good programming etiquette
-Greater stability among collaborative code
-Showcases professionalism



Many thanks for reading and I would be very eager to hear people's opinions.

Regards,
Mike

[EDIT]
Just found the previous attempt to introduce a standard here. I hasten to add that what I propose is a community effort - the previous attempt all seemed very one-sided. I feel that those rules proposed digressed from the whole point of creating a standard because many of the points suggested were simply very irregular ways of doing things. Finally I do not at all like the way it was named a "ruleset" - rules define a singular and strict methodology that is compulsory to follow - a standard is an optional set of guidelines with the intention of bringing improvements about.

We do have a code standard of sorts. The only problem is most of us older coders have been programming for 20+ years before we learned about Darkbasic. Our "code standard" was made up by ourselves without too much outside influence. There are only a few things we have in common like not wanting to use GOTO... and even then some of us are still using it.

We try our best to steer newbies to better coding practices but sometimes they just don't want to listen and want to take their own long bramble filled path.

That is where problems arise because it is necessary to target the standards at a particular type of developer. For a beginner to start learning how to program and then be inundated with programming standards would be very discouraging.

My point is, outside influence is everything. If you just work by yourself, do programming as a hobby with no intention to ever collaborate or move into industry then by all means having your own way of doing things is fine. But as soon as you introduce a third party, or want to progress then I believe that unstructured coding is a severe handicap - both to yourself and the third party (by you I refer to the TGC community as a collective, as opposed to targeting you!).

I personally found it hell trying to learn C because everything was so drastically different from DBPro. Sure, BASIC and C are two completely different languages - but if you bend the compiler slightly (as I showed earlier) then they bare an uncanny resemblance. I think the sooner people start learning code etiquette and starting to follow standard conventions - the easier everything becomes!

Imagine being able to browse the code snippets section, and drop something in to have it work instantly; because it was coded in a way which was portable and thus completely modular - chances are you would not have to modify it to integrate it with the rest of your code. Simple things like being able to look through someone's code and know exactly what's going on without having to figure out how the code is structured. Things like being able to follow tutorials through and have them all make sense because they all follow a unified standard. Having such a standard available to people to use if they wish would make things so much easier for many people.

...or perhaps sometimes You are just too hysteric about your hatred over goto Grog.

Please can we not discuss the place that goto]/i] has in DBPro. Along with [i]gosub it has it uses - though should only be used when absolutely necessary,

Which is never.

Hahaha. I didn't mean to start another GOTO debate (the last one I didn't start by the way). I still am not 100% against GOTO it should be learned by newbies then quickly forgotten. I just used GOTO as a quick example on how we've discovered on our own how to code almost the same while there are still people that do the opposite and are totally fine with those methods.

When people post tutorials we all look at them and if their flawed we tell the poster how to make the tutorial better. Not everybody is going to understand every tutorial despite the way the code is written standards or not.

There are way too many differences in our methods to sit down and say "This is the code standard for Darkbasic for us all."... because you'll find resistance for almost everything you put down as a standard. To get away from GOTO... some things that I see but don't do myself are using constants, super wordy variable names, and defining data type in the function parameters.

However I'm not against making everybodys code better and welcome any attempt at a "code standard"... but it's going to be an uphill battle at an extreme angle.

Oh forget 'goto'! That was the days of the Spectrum 48K, my era.

The last I remember was a convo about functions '()'s and array '[]'s and UPPER case and lower or Both Cases, etc.

The way I see it, stuff the way people type the stuff in, just make sure it works, it's hot and it produces stuff fast without any fiddly bits in between.

If a command works, keep it, if someone makes a fuss that its slow then try and speed it up, if someone complains that something is broke then tell them to get over it (no seriously, it needs repairing). Otherwise, type it in the way it your given.

Some people these days have programming so easy. They oughta have a rewind to the days of writing down assembly code on paper, then converting it the data statements then putting into a computer to find it crashes. Gawd... The easy days now... lol

Comparing Basic to C: Don't read anything cos it'll go on forever too. (my opinion, C/C++ is better but DBPRO is so much easier to learn)... From this you'll get blah blah blah about both...

I will continue to do stuff in C++ and make it compatible with DBPro. I will also do a lot of testing in DBPro because it is still fast.

It's not like comparing an Amiga to a ZX81 here folks... They both run fine...

My motto, type it the way your supposed to. SYNTAX ERROR AT LINE ???

Yeah I remember using reams of paper just to write down LINE statements and PSET (DOT in Darkbasic) to draw graphics in code... before I learned about BSAVE and BLOAD. Of course I'd still have to draw it in code before saving it the first time.

http://en.wikipedia.org/wiki/BSAVE_(graphics_image_format)

Do a lot of people code big projects in DBPro and then when they know more they try to port those projects to C/C++ ? I feel like a large majority of the people here write little demos and short things to test out ideas. In comparison to this usage there are not very many full projects going on. It's tough being a bedroom programmer and finding time to do stuff, especially if you work to pay for the bedroom so I understand why things don't get finished.

I don't think our intention should be to structure DBPro code to be like C/C++ just for the sake of potential porting. I also think the porting model may be difficult no matter what you do. I mean, what's the C/C++ equivalent of intersect object? If you're using DarkGDK then there is a connection, otherwise you're looking at replacing a dozen lines of DBPro code with many times that in another language, or at the very least it would be similar amount but completely different functions and methods from some new library. DBPro does quite a bit in some of those sentence-long commands.

I'm not sure you describe enough positive coding practices but I realize you're just starting the conversation. By the way, it should probably be local testObject as integer.

Each language has good and bad ways of using it which can always be debated ad nauseum. For a couple examples, I feel RiiDii and IanM have a very good style with DBPro code. They use a lot of modularity and "universally appreciated" coding conventions as much as possible. It doesn't necessarily look like C/C++, it just looks well defined and readable. Not using "magic" numbers, lots of #constant definitions so you know what something is for (I really wish we had enums!), and almost exclusive use of functions. I try to emulate these things in my projects and I feel like I have some perty code to show for it.

There is room for personal style, as well. I have a love affair with Finite State Machines and use them everywhere in my code. The main engine loop, enemy AI (of course), object states (animation/action). All sorts of crazy stuff. But it's not right for everyone.

Tiresius, you raise some good points. Most of the ambitious projects I have done have been with the overall intention of porting to C / C++ once a working prototype has been made. A prototype doesn't have to be big at all, in fact they're usually rather small - but when porting you don't want to be having to rewrite the whole thing from scratch.


Perhaps structuring code like C / C++ is not the best idea and another approach should be taken? Though I should make clear that it is not solely for the purpose of portability, as I believe that it introduces good programming techniques as drastically improves readability. The purpose of removing whitespaces from DBPro functions was purely so that a standard naming convention could be established as opposed to portability. Where DBPro functions are used, you would have to replace them anyway as you would be using different libraries to provide the same / improved functionality than in DBPro.


My intention was not to list every coding practice that should be set in stone for that would defeat the point of this thread, in that it should be a community effort - by dictating such practices myself would have a similar outcome to the thread I listed as it is quite clear that programming is very personal. The few I listed were merely examples of what I thought could be improved. Variables declared within functions are local by default.

I would agree with this fully. A standard as opposed to a ruleset allows for personal style and a certain degree of freedom - a ruleset takes away all this by stating exactly what you can and can't use for the sake of unification. A standard is there solely as a set of guidelines which can help make your code more maintainable and introduce good etiquette (and all the other points which I won't list again), it does not in any way state explicitly what you can and can't do - at the end of the day it is there as an aid rather than a law.

We need a Code Complete book, but for DBPro!

I tend to stick with java naming conventions.