Variable Naming - NOT BORING

[Nexus100]

Hi all

just thought I would give you a little insight into the exiting world of variables!!!!

Firstly ensure you use:
Enable Explicit

This forces you to declare variables before use...pain in the rear?? Only in the short term!

Anyone reading this at some point has read some boring text on Naming Conventions for variables....So boring...but hold on..just read on a little before you dive out!

If you are coding something quick and small, say less than 1000 lines and in one file this may seem overkill but pay heed...when you are coding a project which spans several larger files this is super 'd' duper helpful in my humble opinion:

Okay so we all have been told to name our variables something useful and meaningful for easy reading and clarity. for example instead of having a variable named x which refers to a counter into a loop of sprites/lines/whatever....name it something useful such as CounterX. Yeah Yeah common sense I hear you shout...but wait it also makes sense, for clarity, to state what type this variable hold, this goes on to be CounterX.i.

On top of this I would also suggest that you could use the following conventions:

Global Variable: Add a 'g' at the beginning
Protected Variable: Add a 'p' at the beginning

So if we had a global counter as above it would be declared:

Global gCounterX.i

referred to in code later as:

For gCounterX.i = 0 to 100.....

This, although on the surface is really mundane and boring, when you project grows and you add code tested elsewhere or on its own, this kind of convention starts being super useful in debugging...trust me, going through 5000 lines of code split into different files to find that a loop, pointer, sprite position etc is using a global variable for some purpose rather than a protected one, is more boring an painful than implementing this!!

Just a little helper really!

[Little John]

Additional thoughts on this topic:
The world's two worst variable names

Regards, Little John

[buddymatkona]

I would love to see a friendly, BASIC-type language using ENABLE IMPLICIT. I came to appreciate this feature while working on projects with a lot of other people. A convention for implicit types was agreed on by everyone and the result was reading other people's code and my own old code became much easier. I did not have to frequently refer back to the start of a long source code to see what type a variable was.

Here is the way FORTRAN77 did it:

Code: Select all

IMPLICIT COMPLEX(A-C),DOUBLE PRECISION(D),INTEGER(E-Z)

All variables beginning with the letters A through C are of type COMPLEX.
All variables beginning with the letter D are of type DOUBLE PRECISION, and everything else is an INTEGER.

You could easily extend this any way you want:

Code: Select all

LOGICAL  BOOL

Now BOOL is of type LOGICAL and it overrides the default type.

This is the only thing I really liked about FORTRAN.

[MachineCode]

All variables beginning with the letters A through C are of type COMPLEX.
All variables beginning with the letter D are of type DOUBLE PRECISION, and everything else is an INTEGER.

So, that means I can't have a string variable named "mydate" because all "m" variables are integers. How is that good?

[buddymatkona]

> MachineCode

Code: Select all

 String (m)

Or override the default with

Code: Select all

String MyDate

Following an implicit naming convention makes code easier to understand but if using part of the name to define type bothers you, it is just an option .

[Little John]

I would love to see a friendly, BASIC-type language using ENABLE IMPLICIT. I came to appreciate this feature while working on projects with a lot of other people. A convention for implicit types was agreed on by everyone and the result was reading other people's code and my own old code became much easier. I did not have to frequently refer back to the start of a long source code to see what type a variable was.

Here is the way FORTRAN77 did it:

Code: Select all

IMPLICIT COMPLEX(A-C),DOUBLE PRECISION(D),INTEGER(E-Z)

All variables beginning with the letters A through C are of type COMPLEX.
All variables beginning with the letter D are of type DOUBLE PRECISION, and everything else is an INTEGER.

In PureBasic, there is already something like that officially built into the compiler, this is better than any private conventions. When you write a variable, just always add its type, and you're done. Example:

Code: Select all

a.s = "Hello"
b.i = 27
c.d = 1.23

Debug a.s
Debug b.i
Debug c.d

Regards, Little John

[akj]

I recently saw a PB forum post in which Global variables always started with an underscore (e.g. _total) and I think I might adopt this convention.

[buddymatkona]

> Little John
Absolutely right. PureBasic allows you to include the type on the end of the name after the initial definition, so that would be the same amount of
information you get with implicit typing. For lazy people like me, a preprocessor tool could show type throughout the source listing.

[Zach]

I've read lots of opinions on Variable naming conventions.. I've tried a few, I've thought of my own.

In the end I never seem to be able to stick to any though

Personally, I'm not a fan of prefixing names, and I either resort to underscore spacing with Camel_Case, or just plain old CamelCase.
I suppose the one exception is I always put my constants in #CAPS. But they get the unique hash infront of them anyway so that's easy to follow.

[SFSxOI]

In my final code I try to make sure all variables are meaningful and describe what they are doing. For example, i'm currently doing something for work in re-coding a past contract programmer supplied detection module for detecting malware activity in the networking parts of windows based workstations and on networks, this involves IPv4 and IPv6 addresses. The past detection module code is a nightmare, it used short variable names that don't relate to anything they are doing and they are used so many times in so many different places over and over again that even the original coder himself can't follow the flow of his own code. The module works great though but its outdated for the newer IANA conventions, so i'm having to redo it (this time with updating for newer IANA convention via readable database instead of hard coded).

Anyway, If I for example am doing something with an IPv6 literal address i'll have a variable like Read_IPv6Literal$ or something like that depending on what its doing like WriteToLog_Ipv6Literal$ and this way I know what its doing, in this case with the examples either reading or writing an IPv6 literal address. If I have a variable that handles different instances of basically the same thing/purpose I may do something like Read_IPv6Literal_1$, Read_IPv6Literal_2$, Read_IPv6Literal_3$, or maybe Read_IPv6Literal_A$ , Read_IPv6Literal_B$ , Read_IPv6Literal_C$ ,etc.... I don't mind underscores in variables at all as it makes them easier to spot quickly.

I think the "descriptive of purpose/function" variables are more useful, especially in big projects.