death to case sensitivity !

[meems]

>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.

[Derron]

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

[Steve Elliott]

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.

[meems]

>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.

[RemiD]

@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 )


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...

[iWasAdam]

But 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? 

[Derron]

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

[meems]

>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

[TomToad]

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.

[Rooster]

@TomToad
That looks like it would be so nice to use.

[therevills]

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.

[meems]

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.

[RemiD]

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.

[TomToad]

Use this code for an example.

Code: [Select]

#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.

[TomToad]

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.