Obviously the best way to handle variables and methods are just a bunch of garbled letters and numbers.
[QUOTE=sarge997;46654345]Obviously the best way to handle variables and methods are just a bunch of garbled letters and numbers.[/QUOTE]
It's how I handle social interaction too
[QUOTE=ECrownofFire;46654253]For variables in Erlang, PascalCase is objectively better than snake_case or camelCase because the latter two give you syntax errors :v:[/QUOTE]
That's one way to enforce naming conventions.. should add grammar syntax errors too
[QUOTE=ECrownofFire;46654253]For variables in Erlang, PascalCase is objectively better than snake_case or camelCase because the latter two give you syntax errors :v:[/QUOTE]
Now I'm actually talking seriously, do newer languages actually do that and force naming conventions? Regardless of which style you prefer, shouldn't that be open as a choice for the programmer?
[QUOTE=Winded;46654364]That's one way to enforce naming conventions.. should add grammar syntax errors too[/QUOTE]
It has contextual line endings with semicolons, commas, and periods, does that count?
Out of curiosity, how hard do you think it would be to code a basic EPOS program in java? The actual brunt of the program would be simple, but I'm wondering how difficult it would be to deal with a thermal printer / cash drawer.
[QUOTE=COBRAa;46652023](improvements)[/QUOTE]
Hey, thanks! It looks a lot cleaner, now!
[QUOTE=elevate;46653049]I wish C++ fstreams were a bit less ugly. I prefer the syntax of the more type-safe C# BinaryReader.
[code]
//Ugly C++ fstream
int Integer;
file.read ((char*)&Integer, 4);
//Much prettier C# BinaryReader
int Integer = reader.ReadInt32 ();
[/code][/QUOTE]
[cpp]
template<typename T>
T binary_read(std::ifstream &stream)
{
T ret{};
stream.read((char *)&ret, sizeof(T));
return ret;
}
int Integer = binary_read<int>(file);
[/cpp]
Error handling is left as an exercise to the reader
[QUOTE=adnzzzzZ;46654442]Now I'm actually talking seriously, do newer languages actually do that and force naming conventions? Regardless of which style you prefer, shouldn't that be open as a choice for the programmer?[/QUOTE]
i just use whatever naming convention that is the popular opinion for the specific language that i'm writing
it would be awesome if every library written in the same language would use the same naming conventions so that code doesn't look out of place when you mix and match libraries into it
[editline]6th December 2014[/editline]
i feel that coding style itself should be left as a choice for the programmer though
[QUOTE=adnzzzzZ;46654442]Now I'm actually talking seriously, do newer languages actually do that and force naming conventions? Regardless of which style you prefer, shouldn't that be open as a choice for the programmer?[/QUOTE]
Erlang is not a newer language, it's been around since 1986 and open sourced in 1998.
The reasons for enforcing it like that go back to the beginning of Erlang. Basically it was first implemented in Prolog (and has very similar syntax to Prolog), so the reasons for the naming restrictions follow from there.
Now the real reason for enforcing variables starting with an uppercase letter (or underscore, but that denotes an unused/"don't care" variable for pattern matching) is essentially because everything that starts with a lowercase letter is an "atom". To get a nice clean syntax for atoms and still maintain readability, it just forbids you from starting variables with a lowercase letter. So atom is an atom and Atom is a variable, which unambiguously separates the two.
Atoms are also used for naming functions and modules, by the way. Atoms can also have numbers in them so you can have functions like zip, zip3, unzip, and unzip3 (they do what you expect from other functional languages).
For the curious, I believe atoms are similar to the Lisp concept, except that atoms in Erlang can only be strings. An atom essentially acts like an enum except that they're completely opaque and you can't rely on the internal representation. You also can't do stuff like add 1 to an atom and get a different atom (that just gets you a type error), so they're a lot safer. And because of these, you can do stuff like have identically named atoms used in different modules and they won't conflict with each other (unlike in C).
[QUOTE=Dr. Evilcop;46654125]Speaking of, C#'s obsession with Pascal Case is a bit weird for me, coming from Java.[/QUOTE]
Same with Java coming from C#, its all about you're personal preference.
I had a 1 hour discussion about to use or not use 'var' with a classmate.
made this small game a while ago in a day as a joke
[video=youtube;dVtikJtN8Gw]http://www.youtube.com/watch?v=dVtikJtN8Gw[/video]
thinking of remaking it just because
any ideas/suggestions?
[QUOTE=awcmon;46655227]made this small game a while ago in a day as a joke
-video-
thinking of remaking it just because
any ideas/suggestions?[/QUOTE]
Sound.
[QUOTE=awcmon;46655227]made this small game a while ago in a day as a joke
[video=youtube;dVtikJtN8Gw]http://www.youtube.com/watch?v=dVtikJtN8Gw[/video]
thinking of remaking it just because
any ideas/suggestions?[/QUOTE]
Use this for sound
[video=youtube;-w9PukG97oQ]http://www.youtube.com/watch?v=-w9PukG97oQ[/video]
[IMG]http://i.imgur.com/JsOV9tt.png[/IMG]
OpenGL font rendering using freetype.
As you can see it is going well.
[QUOTE=adnzzzzZ;46653741]likeThis for methods
LikeThis for module/class names
like_this for variables
If you do it any other way then you're a pleb[/QUOTE]
The way I learned, underscores should be reserved for constants or macros, which should be in all caps
#define SOME_MACRO 22;
const int SOME_SHIT_THAT_NEVER_CHANGES = 22;
LikeThisForClasses
likeThisForMethodsAndVariables
[editline]6th December 2014[/editline]
[QUOTE=COBRAa;46653828]If you have a function that long, then you're doing something wrong.
If you're really *that* desperate: this_is_an_object_that_does_a_thing.
It's just, camelcase is so 'off-balance' to my eyes, I literally can't use any API that uses it. Seriously, if you're going to capitalize any of them, capitalize them all.
[editline]6th December 2014[/editline]
ThisIsAnObjectThatDoesAThing > thisIsAnObjectThatDoesAThing[/QUOTE]
First Capital letter should be reserved for class names.
we have these conventions so that at a glance we can identifiy what certain elements are without hunting down their headers
All uppers for constants
Always start with capital letter on public variables
Always start with lowercase letter on private/protected variables(but following words in the name should be uppers)
underscores before name for _local variables
That's what I learned.
Update on my little game thing (I haven't done one in a while)
I've almost got a grid system working for collision detection, I've just had a lot of problems with it so that's why it's been taking me a week or two (mostly just being frustrated, shutting down netbeans, and eating ramen).
After all this is accomplished, I might focus on adding some actual gameplay elements or particle effects! So far, the score is based on how many asteroids you kill, and each asteroids splits into smaller and smaller asteroids. And that's it!
[editline]6th December 2014[/editline]
[QUOTE=cartman300;46655286][IMG]http://i.imgur.com/JsOV9tt.png[/IMG]
OpenGL font rendering using freetype.
As you can see it is going well.[/QUOTE]
I tried that before (two times actually) and both times I spent a week on it, and it never drew anything, even when I desperately tried to copy and paste code from a wiki tutorial on this, after writing it myself. I got so frustrated! Congratulations!
[editline]6th December 2014[/editline]
Also, thanks for the highlight in the OP! I appreciate that a lot, especially when it's comparatively nothing to what everyone else in the thread has accomplished. One day, I want to make what you guys make! Maybe once I'm through with my first year of college as a CS student. (:
[QUOTE=Fatfatfatty;46655745]All uppers for constants
Always start with capital letter on public variables
Always start with lowercase letter on private/protected variables(but following words in the name should be uppers)
underscores before name for _local variables
That's what I learned.[/QUOTE]
Variables prefixed by underscores are reserved for the implementation in C++.
[img]http://i.imgur.com/J5STv77.png[/img]
The fuck is wrong with glyph width.
[QUOTE=Fatfatfatty;46655745]All uppers for constants
Always start with capital letter on public variables
Always start with lowercase letter on private/protected variables(but following words in the name should be uppers)
[B]underscores before name for _local variables[/B]
That's what I learned.[/QUOTE]
Fuck no. Why would you prefix the gross of variables?
And when is the last time you saw somebody do.
[cpp]
for(int _i = 0; _i < _length;_i++)
[/cpp]
Well, someone told me that at some point and i just stuck to it, sorry.
[QUOTE=Fatfatfatty;46655971]Well, someone told me that at some point and i just stuck to it, sorry.[/QUOTE]
Should have banned Altimor earlier.
[QUOTE=elevate;46655866]Variables prefixed by underscores are reserved for the implementation in C++.[/QUOTE]
That's only if they start with an underscore then an uppercase letter.
[QUOTE=Fatfatfatty;46655971]Well, someone told me that at some point and i just stuck to it, sorry.[/QUOTE]
I usually use no prefix for local variables, and m_ for private members because this.x = x is a little hard for me to read.
[QUOTE=ECrownofFire;46656001]That's only if they start with an underscore then an uppercase letter.[/QUOTE]
I know that 90% of the microsoft C CRT implementation starts with an _(and then an has an macro that points to it that starts without the _)
I think its not the only time I've seen that either.
[QUOTE=ToXiCsoldier;46655186]Same with Java coming from C#, its all about you're personal preference.
I had a 1 hour discussion about to use or not use 'var' with a classmate.[/QUOTE]
I personally never use loose typing in a language that supports strict typing.
Off the top of my head, C# and Flash ActionScript are the only two that do it. In both of them, I [b]never[/b] use "var". I like the safety that explicit types provides, and prefer to use it whenever possible.
When dealing with loose languages, like Lua, it's not exactly crippling though. I personally just tend to imply the type in parameter names, like strFilename, or intCount, or floatWeight.
I also use Java-esque camelCase whenever and wherever I am. Java, ActionScript, C, C#. Doesn't matter, I use camelCase. Majority of the code I write will never be seen by anyone but me, and so I write it the way I am most comfortable with.
Again, that's all personal preference, though.
[QUOTE=Fatfatfatty;46655745]All uppers for constants
Always start with capital letter on public variables
Always start with lowercase letter on private/protected variables(but following words in the name should be uppers)
underscores before name for _local variables
That's what I learned.[/QUOTE]
Variables should be private, methods should be (mostly) public. Use get() methods to return variables.
fyi var is type safe. If it wasn't there wouldn't be a difference between var and object. var in C# is not the same var in JavaScript, which isn't type safe.
The type of var is the compile time type of the right hand sideof the assignment. That is why you have to initialize a var when you declare it. AKA this is illegal:
[code]
var myVar;
[/code]
The purpose of var is this:
[code]
List<List<SomeVeryLongName<SomeGernic>>> GetLongNamedVar() { //... }
void Foo()
{
// long line to declare a variable with this type
List<List<SomeVeryLongName<SomeGernic>>> myThing = GetLongNamedVar();
// Declaring a variable with the SAME TYPE but saves space
var myVar = GetLonNamedVar();
// the type of myVar is now List<List<SomeVeryLongName<SomeGernic>>>, so it is completely type safe and saved me some space
}
[/code]
That being said I never use it. It is clearer to a programmer looking at the code what the type is if you explicitly state it.
We're working on our Ludum Dare game!
[IMG]http://i.imgur.com/Tu428La.png[/IMG]
Sorry, you need to Log In to post a reply to this thread.