So this follows a post by iWasAdam about case sensitive languages
Thought it deserved its own thread.
Quotevariable would be used within a function/method and would probably be local
Variable could be a function or global within a class
VARIABLE would usually be a const or static of some form - generally predefined elsewhere
_variable / _Variable usually internal class stuff
So Variable would be the access point for the internal _variable class definitions
vArIAble, variABLE are just dumb and are sackable offenses :P
In essence (on the surface) they all are the same, but in practice there is a general programming method to naming.
Where this becomes more important is with the following sort of stuff
PageCoreTileNum.Value is far more readable than pagecoretilenum.Value and is easier to read (quickly) than Page_Core_Tile_Num.Value where the _ sort of breaks up the flow
Whereas
KEYPRESS_M
STORM_FOUNTAIN
MOVEMENT_LEFT
becomes easier to read and instantly recognisable as some form of static/const that is pre-defined
There are other notations which have the base type also added. E.G.
fX = float value X
iX = int value X
bX = bool value X
strX =string value of X
Again this sort of use allows someone else to instantly look at the code and know what is going on without resorting to finding header files, etc.
I agree with the rational for case sensitivity, it is a good idea to store info in names of variables for easier understanding.
But making the programmer do the case sensitivity is exactly the wrong implementation of this rational.
Are you aware there has been a different approach? One that is at least as old?
Here's a clue from 1991
(https://i.imgur.com/I2yV28o.png)
Blitz2 on the amiga. Nothing special about the case sensitive style. Most languages do it then and now. The letter-case of the terms are auto adjusted by the ide. They are also auto coloured by the ide. This the correct approach to case-sensitivity. The ide should do the legwork, not the programmer.
Many programmers believe that languages that don't require the programmer to do the case sensitive legwork aren't case sensitive, even though the ide's of these non-case-sensitive languages are strict about keywords starting with a capital letter.
Well, such an opinion isn't totally wrong, its an over generalization of the fact that variable names aren't case sensitive in so-called case insensitive languages.
But in the modern guise of case sensitivity, we aren't focused on just variables. The programmer is expected to do the legwork of capital first letters for functions and methods, and all caps for constants.
solution: extend the auto correct usually reserved for keywords to all words.there should be a philosophy of
minimizing the need for the programmer to work the case sensitivitythe ide should pick up on new terms introduced by the programmer and auto correct the letter case. Once a new term is declared, all other case variations of it become unavailable.
e.g
A new variable is declared, the ide will auto correct to always be in lowercase
A new constant -> ide always autocorrects to uppercase
new function\method -> ide autocorrects 1st letter uppercase
for multi word terms that punctuate each word with a cap, the ide can follow the user's caps at the declaration\definition of the term.
simple, and it would be absolutely great. Which ever language programmer implements this into his language deserves a statue in silicon valley.
Leave you with this final thought. Imagine all those times in blitz, on the amiga, on the PC in 2000, in blitz3D, in blitzmax, and many other languages. Imagine if every time you made a for -next loop, or a while loop, or any other key command, you had to do your own capital 1st letter. Fuuuuuuu. what a pain. Now realise this is the reality you've accepted for many languages. Including cerebus. argh. plz. no.
It shouldn't have been, but I can't pretend, case sensitivity was a significant factor in my decision to not to use cerebus.
What you think? Even though i feel strongly about it now, I leave room to believe I'm wrong. I'm interested to know if programmers seriously tried to go down this road, but found it impractical.
Quote
The ide should do the legwork, not the programmer.
I totally disagree with this statement. That means the IDE is correcting a flaw in the design of the computer language.
IDEs do the "beautifying" - like autocapitalization, or maybe "unifying" variable names (you declared "mySuperVar", and the IDE corrects follow-up variations like "mySUPERvar" to "mySuperVar").
The language itself should be not case-sensitive. It also should not allow "non ascii-chars" (and even there, not all) in variables - to avoid ambiguity and it eases the pain for newcomers to a language.
bye
Ron
I'm in the pro case sensitivity group :P
It forces consistency and in programming that is super important.
The "main" programming languages are case sensitive: C, C++, Java, C# where as most beginner languages are not... there is a reason for it :)
@steve
so u think the vast majority of languages and their ide's are wrong on this. It pains me to have to do caps for keywords. But it pains you everytime your ide autocorrects your keywords e.g. ( For While Function )? Do you type the cap yourself even though the ide would have done it for u?
@therevills
>I'm in the pro case sensitivity group
so am i. I just think the ide should do it. Not the programmer.
>The "main" programming languages are case sensitive: ... there is a reason for it
Yes because they're all dumb, and following each others wrong lead in a circle of dumb sheep. plus they are very set in their ways, they can't change now.
Its abit crazy that both approaches are implemented into modern languages, both ide auto corrects for some arbitrary keywords but not all, and programmer has to do the others, ones that have been put in a non-core module so don't get the accolade of being an ide auto corrected term.
@meems
I just re-designed the language instead.
Quote
I'm in the pro case sensitivity group.
It forces consistency
It clearly doesn't.
>I just re-designed the language instead.
Great! Show us with a before and after re-design. Color me skeptical until u do though. I find it hard to believe u've hacked into blitz and other languages to stop the ide from recognizing key words.
>It clearly doesn't [force consistancy].
Its not clear to me. give example of it not forcing consistency plz.
Quote from: meems on February 28, 2018, 22:03:40
Its not clear to me. give example of it not forcing consistency plz.
String mySupERVAR
String myOtherVar
String mylowercasevar
The consistency is just that variations of the casing will create new variables (or errors for nonexisting ones). But it does not enforce you to use "lower Camel Case" or something else which creates "visual" consistency (except for eg. first character needs to be Upper-case or so).
bye
Ron
Bad code is bad code and can be created in any language.
A case sensitive language with a good coding standard will force consistency, if one programmer calls a variable "myFieldAdapter" then all other programmers will have to use that variable in that form.
well any case sensitive language that doesn't require the user to explicitly declare variables is just asking for a rash of totally avoidable runtime bugs. What languages are like this? I generously assume that no such language exists these days. iirc java used to have implicit declaration, so if you got your caps wrong you only found out when your program acted weird. Haven't they fixed that shit yet?
Quote from: meems on February 28, 2018, 22:30:45
well any case sensitive language that doesn't require the user to explicitly declare variables is just asking for a rash of totally avoidable runtime bugs. What languages are like this?
Main one is is JavaScript (nothing to do with Java)... its case sensitive and dynamic.
@ meems
use PHP and you are able to use undeclared variables.
use Javascript and undeclared variables are handled as globals.
...
@ good coding standards
Feel free to have them in a case-insensitive language too. It is up to you to keep conform with them. And if you have a good IDE (sorry BRL-languages ;-)) then it would allow you to auto-format according to the initial definition of the variable, function name (talking about the casing).
Case-sensitivity is nearly as "odd" as the intentation-interpretation of Python.
bye
Ron
@meems
I wasn't talking about a Blitz Language. Something for the near future.
Quote from: Derron on February 28, 2018, 22:37:08
@ good coding standards
Feel free to have them in a case-insensitive language too. It is up to you to keep conform with them.
Yep we do. In my current job, the GUI is a Java Swing application with an Oracle PLSQL backend. PLSQL is case-insensitive and we have peer reviews in place to ensure everyone confirms to the strict coding standards (as well as making sure the code makes sense).
Quoteuse PHP and you are able to use undeclared variables.
use Javascript and undeclared variables are handled as globals.
the absolute state of programming languages in 2018. should have been fixed in the 80's.
@steve
well make sure it implements my awesome idea of automated caps corrector for all terms and not your rubbish idea of no word recognition. you will secure your place in silicon heaven
I'm getting the impression that no language has ever done my awesome idea. I knew i was good, but i didn't realize how good. Am i really that good?
>we have peer reviews in place to ensure everyone confirms to the strict coding standards
that this is necessary is not a good thing. It can nearly all be done by an ide if u instruct it right.
coding standards are not just formatting/casing things but also the way you use stuff ... declaring variables at the top of a function, when to use bla[i++] and when to avoid such stuff etc.
With plenty of things an IDE could assist you, but certainly not all - and some of this stuff can belong to coding conventions/guides/rules.
bye
Ron
Quote
but i didn't realize how good. Am i really that good?
No, you're not meems...Good at being rude, arrogant and annoying people maybe. Thinking you know it all, when you clearly don't.
>No, you're not
implying you know of an language or ide that has already implemented my idea. cool. But why didn't you provide a link? just finding it now? ok i believe u. But don't be offended if some find your words are hollow. you should at least occasionally provide evidence when asked when u have no reason it hide it.
@meems>>i am more good than you ! so much more good that i did not use the arbitrary exception "better" (instead of "more good"), you realize the truth now ? ( just trolling the troll :P )
on topic : i am against anything which force the programmer to adopt a specific programming style, or some arbitrary rules (like case sensitive), i code the way i like (that's why i like blitzbasic and php) and i manage to understand most of the codes written by others, whatever their programming style, but i admit that i prefer the imperative style which looks like english.
however, it is clear that a variable name or function name with uppercase for the letter of each word in the name is easier to read than all lowercase...
RebuildSurfaceWithSharedVertices(Mesh,Surface,OMesh,OSurface)
vs
rebuildsurfacewithsharedvertices(mesh,surface,omesh,osurface)
also i understand that if you work with others programmers, you have to follow some rules in order to have your code understood by others (and to understand others's codes), and to make a part of code compatible with another...
QuoteBut making the programmer do the case sensitivity is exactly the wrong implementation of this rational.
Yep, most IDE's will auto capitalise keywords such as Cos/Sin if that is how the language works.
But for variables it is up to the programmer to do it as that would mean the IDE would have to have language knowledge.
E.G.
myleftfoot = MyLeftFoot or Myleftfoot?
pantone = Pantone or PanTone or PantOne or pAntOne?
That sort of thing becomes semantic analysis, and is incredibly hard to do for a single language (such as english), when you throw in other languages (french, spanish, mixed laguages, etc) the semantics becomes even worse. E.G. impossible for a machine to get the meaning.
The alternative is uber strict type definitions.
What this means is you can't use a variable without properly defining it first. E.G.
Local myVar:int
(in most programming situations that is always good practice anyway. And most places have their own styles for this - as do programmers)
typing myvar would automatically check for existing variables and definitions. The IDE would attempt to replace it with what it thinks is correct.
type novar would stop the IDE further until you defined the variable.
This would get nasty and also get annoying, but would answer the problem of "I'm too lazy to bother about capitalising things and think it is someone elses' problem"
Again this is great if YOU are the only person who deals with your code and can easily read thisismyvariableforpissingoffpeoplejustbecauseicanandsothereupyoursmateyyahboosucksiamthegreatestprogrammerintheworld
I think we're done here? :P 8)
Modern IDEs come with semantic parsers, lexers, ... so they analyse your code.
If you are in a case-insensitive language, then an IDE wont format variables which were not defined before (except they allow the definition of a "coding style" - so eg. adding "T" to Type classes, having UpperCamelCase functions ...).
If you once defined "function myUtterlyWrittENone" then the ide takes this for granted and would auto-adapt the other writing-variations while you type.
> pantone = Pantone or PanTone or PantOne or pAntOne?
While I found "PantOne" funny all these things could - and should - mean the same. If the developer knows this, then they just use a different variable name to distinguish things.
clothingPantOne
colorPantone
...
And NO do not say this enforces developers to be more verbose than needed. What happens if you have the variable "housing" - it means different things, so if you want to use multiple meanings of this word, then you need to use multiple variable names. or just think of "bone"
local bone:3DBone = dog.bone.bone
local bone:TSkeletonBone = dog.bone
ups... see it does not matter if case sensitive or not.
For me using different cases in a programming language should only be to ease readability for human developers. Compilers, software analysis ... they all should be able to understand things perfect based on the syntax. I mean: compilers have no trouble to work with variable names "forewfnorengornlknblb" - while human ready will have trouble, regardless of uppercased, lowercased, camelstyled or not.
And no ... the times of performance issues (checking "MyDraw()" vs the defined "Mydraw()") can get ignored today - it is a one time step for compiled languages. This might have been an issue for the first languages but not todays ones.
bye
Ron
>But for variables it is up to the programmer to do it as that would mean the IDE would have to have language knowledge. ...
>That sort of thing becomes semantic analysis, and is incredibly hard to do
nope. loads of ides (e.g Notepad++) do it for any arbitrary language, and can do w/o knowing any of the language. They just pick & store the programmers words. Except they aren't strict on case sensitivity as far as I'm aware ... hmm, there's a fair chance though that I haven't explored the power of these ide's and they can be tuned to do case sensitivity!
Also I'd get a much better response from the ide dev crowd on their forums than from you lot, I feel most of u haven't fully grasped what I was saying + u are for some reason opposed to this idea, I think you are just conservative and superstitious, i.e. fear of the unknown + blind faith that the system u know so without question will argue for it against any and all reason.
>This would get nasty and also get annoying
You sound like u haven't used an auto complete ide. They are very nice.
>The alternative is uber strict type definitions. What this means is you can't use a variable without properly defining it first.
That's just normal strictness, and as you say, its normal to enforce it and considered good practice. So nothing lost
Problem with case sensitivity is that you can use the exact same word for different concepts. For example:
MyCar myCar, Mycar, mycar; is valid c++ code. You have declared 3 different variables as class MyCar. As code gets larger and more people work on it, similar variable names like that will crop up. When you read over the code, it gets difficult to figure out which "my car" you are looking at.
With case insensitivity, you are forced to use unique names each time. So above would be rewritten something like TMyCar MyCar1, MyCar2, MyCar3. Now you will see instantly later in the code which "my car" you are referring too. Also less of a clash should someone try and use a "my car" variable later on.
As for having the IDE do things for you, I like the way B4X handles things. You define the variable before you use it, MyCar1 as MyCar, then when you type it again in the IDE, it will pop up an autocomplete prompt with the defined case, so you just need to hit tab to insert it.
(https://www.syntaxbomb.com/proxy.php?request=http%3A%2F%2Fwww.tomtoad.com%2Fimages%2FIDEac.gif&hash=15b7825f9a2d4820969d4d25442740908418b85a)
@TomToad
That looks like it would be so nice to use.
Quote from: TomToad on March 01, 2018, 09:44:07
Problem with case sensitivity is that you can use the exact same word for different concepts. For example:
MyCar myCar, Mycar, mycar; is valid c++ code. You have declared 3 different variables as class MyCar. As code gets larger and more people work on it, similar variable names like that will crop up. When you read over the code, it gets difficult to figure out which "my car" you are looking at.
That's why you would use a good coding standard, in Java MyCar would be the class and myCar would be the valid variable name. Mycar and mycar would fail code review.
If you are coding and switching between myCar, mycar and MyCar in a non case sensitive language something is wrong with your programming style.
on the contrary, as long as the language is case insensitive, it doesn't matter what you do with caps in your words. But if your language is case sensitive, and u are using myCar, Mycar, MyCar, MYCAR, mycar - Then u need to see a doctor.
A decent ide & case sensitive language would stop u using different case variations from the original definition of the user defined word, and strictly auto correct your words to the case variation used at the word's definition. ( as i keep saying )
Languages that let u use different variations of caps on a single word to mean different things, they are misguided and prone to programming bugs that are totally avoidable but for this. And they are harder to read.
Quote
on the contrary, as long as the language is case insensitive, it doesn't matter what you do with caps in your words. But if your language is case sensitive, and u are using myCar, Mycar, MyCar, MYCAR, mycar - Then u need to see a doctor.
Especially if you have to reread one of your old codes that you have not opened for years, and you have to remind yourself that one name is for this and another name for that, but they are all written with the same letters, but not with the same lowercase / uppercase.
I can't imagine to have to debug such codes, it is like voluntarily "obfuscating" your codes against yourself. ???
Use this code for an example.
#include <iostream>
using namespace std;
int Wheel = 10;
class MyCar
{
public:
int wheel;
MyCar()
{
Wheel = 5;
}
};
int main()
{
MyCar myCar;
cout << "Wheel = " << Wheel << ", myCar.wheel = " << myCar.wheel << endl;
return 0;
}
Now this example is just a scaled down, bare minimum example of the problem. In reality, this would probably be a much larger project. The global Wheel might be tucked deep inside a sub-header of another header inside a physics library that you imported. The class MyCar would probably have hundreds of fields, defining many properties of the car, with dozens of methods operating on the car.
In this small example, it is easy to see the bug. In the programmer's attempt to create the constructor, maybe a midnight programming session, or a lot of stress, or a rush to get the project done, his finger slipped onto the shift key and he typed Wheel instead of wheel, changing the global value instead of initializing the field. When he looks at the code, trying to figure out why his car is not moving correctly, he will look over the many fields and many functions. He may look right at the bug, but our brains wants to read Wheel as "wheel," not as "capital W, small H, Small E, etc..." So he can look right at it hundreds of times without even realizing his mistake. He might be totally unaware of the existence of the global, so he has no reason to suspect the wheel variable is the problem over any other variable, or even just a coding mistake.
Now go and change the field "int wheel;" to "int Wheel;", and the "myCar.wheel" in the cout statement to "myCar.Wheel". This will emulate a case insensitive language as much as possible in C++. Now when you compile the code, it will work. That is possible because the compiler is smart enough to know that Wheel in the constructor refers to the field instead of the global. Some languages go a step further and prevents you from redefining a global as a local variable, causing an error. (Actually I'm surprised that MinGW isn't at least throwing a warning here.)
Having a case insensitive language doesn't mean you should type everything as lower case. You can still use a convention when naming variables. I tend to capitalize the first letter of each word, so I would use MyVariable. You can use a prefix or suffix to indicate classes or globals. It is easier to know you are looking at a class at a glance with CMyCar or TMyCar than it is with just MyCar. When I am reading code that I haven't written myself, I tend to read MyCar as "my car" not as "Capital M, small Y, capital C, etc..." I am forced to slow down and look at it closely, which interrupts the flow of reading.
I was using myCar, MyCar, mYcAr, etc... before as an example of code that is valid. I wasn't implying that it was acceptable coding, but possibly come about as a mistake. A slip on the shift key that could inadvertently create that situation and be difficult to track down if your program is large.
Quote from: TomToad on March 02, 2018, 13:15:03
Use this code for an example.
...
Now this example is just a scaled down, bare minimum example of the problem. In reality, this would probably be a much larger project. The global Wheel might be tucked deep inside a sub-header of another header inside a physics library that you imported.
And here's the problem. Using globals in larger projects is just a big NO NO. So when you rely on globals in larger projects you have clearly some design issues.
In C++ you have tools for static code analysis (like lint) which would prevent you from doing that anyway.
In C# you can have the same variable name as a type name, which I think is rather stupid but still... we are talking about MS :P
public class MyClass
{
private int variable = 10;
MyClass()
{
// maybe do something
}
void Pointless()
{
MyClass MyClass = new MyClass();
MyClass.variable = 20;
}
}
>In C# you can have the same variable name as a type name
that plays to my suspicion that at least half of all work in the programming industry is faux, just chopping sand with a breadknife for lack of decent work to get paid for. A dreadful language design to tie programmers in their own knots, and get paid for untying themselves.
Quotethat plays to my suspicion that at least half of all work in the programming industry is faux
You can say the same of that with all industries - most use fancy ideas, practices and vocabulary that isn't used by regular public in order to keep those 'untrained' out.
For a good example just look at the legal systems that are in place with its fancy methods of working and fancy words that only lawyers understand, most of which could just as easily be expressed using regular language that EVERYONE can understand. It's all about keeping those who know 'in' and those that don't 'out' - justifying your position and all that crap. The more you learn about this kind of stuff then the more you may be disappointed - personally I find it all rather fascinating and predictable but meh that's just me.
People enjoying case sensitivity surely also enjoy writing without brackets ;-)
Superstrict
Import Brl.StandardIO
Type TAddList
Method AddList:TAddList(addlist:TAddList)
return addlist
End Method
End Type
local addList:TAddList = new TAddList
if addList addList.AddList addlist
if addList addList.AddList(addlist).AddList Addlist else new TAddList.AddList new TAddList
bye
Ron
Brackets serve a purpose. They are not there for nothing ;)
Semi-colon at the end of every single statement I find a waste of time.
Case-Sensitivity I'm not so bothered about. I use Visual Studio Pro 2017 at work and it has quite possibly the best editor I've used so case-sensitivity isn't really an issue for me personally. VS also has, arguably, the best debugger too.
When doing work in the laboratory the computers there are xeons (8core) and with its remote drives and some other limitations start up times for VS Studio (or Atmel Studio - based on VS) is crying: go out, make a break, come back in 2 minutes).
also IntelliJ is taking some seconds more than needed.
So if you want to test a small thing you might need to wait longer for the start up finishing than for the actual coding.
But hell yes, these IDEs are real beasts. Think most of us wont use all the stuff they provide. With BlitzMax or Monkey you most often would only need the debugger (breakpoints and stack analysis). Some simple refactoring (variable renaming and so on) and some kind of intellisense (autocomplete-list + inline function definition tooltip). Such a cut down version would have way shorter start up times...
I almost everytime use the brackets in function calls ... list.AddLast(obj) etc.
Only exceptions are
SetColor 255,255,255
SetAlpha 1.0
print ""
Somehow I am so used to these that I skip the brackets there... Maybe this is also because you do not "chain" or evaluate them (if print("bla") then...).
@ code guidelines
Maybe just use UpperCamelCase for functions, prepend "T" to types, prepend _underscore to private variables (if "private" is not supported by the language), UPPERCASE_UNDERSCORE_CONST for constants and lowerCamelCase for variables.
You will embrace the C-coders, people are able to read it properly and you avoid hungarian notation (Saw it very often in micro-C code) means prepending the variable type in front of the variable.
Fixing variations of this could be done by the IDEs code-beautifier / formatter.
bye
Ron
@col
yes i agree. I'm a geology hobbyist and they might as well have their own dictionary. A few jargons are necessary but once u understand the lingo u realise a lot of its there just to sound clever.
Case Sensitive=time consuming
You need to check everytime what you are writing, it's a waste of energy
A nice read:
https://blog.codinghorror.com/the-case-for-case-insensitivity/
yeah... $fileName versus $filename. I tend to use $filename though I try to use lowerCamelCase for most variable names and UpperCamelCase for functions/class names.
bye
Ron
Quoteyeah... $fileName versus $filename. I tend to use $filename though I try to use lowerCamelCase for most variable names and UpperCamelCase for functions/class names.
In VStudio, a C# project will highlight that a method name starting with a lower-case is, and I quote...
'Naming rule violation: These words must begin with upper case characters: 'and places the 'offending' method name on the end.
*sigh* and there was me thinking that it was me that's supposed to tell the computer what to do, not the other way around :D
> *sigh* and there was me thinking that it was me that's supposed to tell the computer what to do, not the other way around
Hah, this changed in the 80s of the last century. "In computers we trust" is what could get printed on modern Dollar notes.
bye
Ron
A brief scan of the ideas in this thread shows me that zome of the thoughts expressed never make it to industry or the real world.
Eg.
At work-
The language we use treats database field names as globals throughout every program and core and custom programs use global vvariabls absolutely everywhere ( we prefix them with ws- 'working storage')
Case sensitivity is a beautiful thing to me.
The ide we use at work is terminal based unix 'vi' - no colour, no mouse driven features, full of arcane hot keys even exiting is mysterious (press escape then colon plus 'q!' to exit - cant exit with standard windows methods)
you really ":q!" ? Never lost unsaved changes?
Without case-sensitivity you cannot prepend "ws-" to your globals? What do "[...] treats database field names as globals [...] " have to do with case-sensitivity?
Only possible answer is: your database is case-sensitive already, enforcing you then to take care of this case-sensitive field names ...
bye
Ron
@Matty
>shows me that zome of the thoughts expressed never make it to industry
> implying that if syntaxbombers have a good idea, we can get it into industry languages in under 6 weeks
Sadly, you think too highly of us. If you are expecting us to get our better ideas into Java 10 and C# 7.4 then you're going to be disappointed. I'm flattered , hey, I know I'm ace, and I don't need anyone to tell me, but its best you understand I'm not the CEO or lead dev at Oracle or Microsoft.
Me... I like to instantly see what the code is telling me. so I use the following:
methods/functions = CamelCase
local variables = lowerCase
class variables _lowerCase
constants = UPPER_CASE
other variables name exist - you then have to hunt for were they are set. if not local then check the private then protected then public areas. After that... phone home and ask for help ;)
@ adam
you prefix all class variables with "_" underscore? I would have assumed people use it to define them as "private properties" (if the language does not offer a "private/public" portion in classes/types).
Else I use exactly the same (ok, had a time with "set***()" and "get***()" being written lowerCamelCase too ... dunno why)
bye
Ron
Here at work we use _variableName for all class members as well. That way you instantly see what's a member and what's not. It's in our coding guideline (plus tabs to spaces as well! :) ) Oh, we use C++ here. What a beast!
QuoteHere at work we use _variableName for all class members as well.
QuoteOh, we use C++ here
I'm sure you're waiting for this already so I'll bite :)
In the C++ coding standard it states
Quote"Don't overlegislate naming, but do use a consistent naming convention: There are only two must-dos: a) never use "underhanded names," ones that begin with an underscore or that contain a double underscore;"
(p2 , C++ Coding Standards, Herb Sutter and Andrei Alexandrescu).
I usually use the underscore style in BMax for private variables, but in C++ I generally use m_ for member variables and g_ for globals.
Haha good one and I tend to agree. But... I can't do anything about it here.
Quote
Me... I like to instantly see what the code is telling me. so I use the following:
methods/functions = CamelCase
Don't Mark's languages precede methods/functions with either the word method or function? So that tells you what it is lol. I guess you're talking about *calling* a method/function. Even then is a distinction really necessary as methods/functions are followed by brackets which indicates a method/function, rather than a variable name?
Quote
local variables = lowerCase
class variables _lowerCase
What is the difference here Adam? Class variables are member variables and a class should be a self contained unit, with data passed-in if appropriate.
And yes, col's correct when using C++ - do not use underscores to precede a variable's name.
> Even then is a distinction really necessary as methods/functions are followed by brackets which indicates a method/function, rather than a variable name?
function MyVar:int()
return 10
end function
print myvar * 10
Fair point. :)
But shouldn't it be print MyVar() * 10
it should - but it isn't needed (at least in BlitzMax) - at least not in call cases.
above's example btw fails:
Compile Error: Types 'Int(Int)' and 'Int' are unrelated
bye
Ron
Then it's the language that is at fault, leading to people having to clarify using case sensitivity.
Mine is simple.
Everything in lowercase except constants which are all caps.
@Steve
With monkey you have properties - that are sort of like variables but can also do lots of other stuff too.
e.g.
Class Channel
Method New()
End
Property Stereo:bool()
Return _stereo
Setter( stereo:bool )
_stereo = stereo
End
private
field _stereo:bool = False
End Class
Local myChannel = New Channel
myChannel.Stereo = true
Print myChannel.Stereo
_stereo is private and we cant access it
but with setters and properies we can both set and see what it is - we can also add other code in these too...
But <WARNING> You must watch the cases and what variables you are dealing with in the properties and setters. otherwise it will all go Pete Tong!
Quote
But <WARNING> You must watch the cases and what variables you are dealing with in the properties and setters. otherwise it will all go Pete Tong!
So it's Mark's Monkey Madness then lol. :P
yep. wait a minute.... thinks and looks at really old blitzmax code
Yep using _ as the first character is definitely a monkey2 Mark thing :))
interesting to note that it is 'illegal' in c++ to do it (which is what monkey2 compiles into).
Quoteinteresting to note that it is 'illegal' in c++ to do it (which is what monkey2 compiles into).
As it's 'trans-piled' into c++ you can prepend anything you want for the c++ code. It would be probably end up as something like bb_varname in c++ when the coder used _varname in the monkey code.
Just had a quick look into the transpiled sources...
mx2 code
field _gameTrigger:int = 400
transpiled code
bbInt m__0gameTrigger=400;
Interesting that it contains a double underscore.
I can understand not starting variable names with underscore(s) as there is a general rule that they are reserved for the compiler chain, but 'containing' underscores... I'm not sure why that's a rule in c++. Meh... in the meantime... on with some coding :)