I agree with Neil, You've got to go with what works for you. Familiarity is always a factor.

I remember writing in QBasic Interpreter years ago. I installed Quick C 2-3 times before making myself use it. It didn't make much sense at the time to go though all the setup with includes and main() and {} etc when I could just say PRINT and BAM there it was. I did learn over time though that with complexity can come options.

I guess the trick is to determine what you are looking to get accomplished and how much effort you are willing to put in to getting the desired results. How much do you want to know about the details, or how much you'd rather use a black box approach with language commands/ macros.

I also agree with Neil in that global scope taboos are often overstated. I have wasted a lot of time trying to "be a good programmer" just to realize there is nothing wrong with a global variable on occasion. . It's much like I don't agree with never signing on as Root in Linux either. I ONLY sign on as Root. See I live on the edge like that..

I used to program in QBasic and QuickBasic 4.5 (compiled version). What helped me move to C was a great book I found called QBasic to C. It got bad reviews as they stated that it didn't teach proper C, which as usual, was nonsense. It done what it said, it showed you QBasic and then showed you how to do the same in C. Hardly useful these days as nobody starts out with BASIC anymore, but great at the time. From there I used DJGPP under DOS and started to program my own library for graphics by reading various resources I found that helped me learn how to access video RAM etc... when I found Allegro I abandoned writing it myself. I wish I had never found Allegro now as I would have continued programming my own library and probably gotten a lot further.

I still have some of my original library code and QuickBasic code. Good times, I miss those days honestly (in the'90s).

I still have the DOS source for my first Allegro game I ever completed. I was just playing it today (an Artillery Duel game I called "Deluxe Artillery Duel") which I completed in 1999. I am thinking of resurrecting it and remaking it just for fun. It's funny to look at my code from back then. I still had many bad habits. While I don't mind globals, I had WAY too many of them back then!!! LMAO, my coding style wasn't set either, fascinating to look back at. Glad I'm a packrat and keep all these things. I still have Deluxe Paint 2e I used to make my graphics with.

I went from BASIC in middle school (7th & 8th) to C++ in high school. I dabbled in other languages, but can't say I've made anything of substance with other languages.

The oddest thing I've ever seen has to be when a guy declared all his functions at the start of the program and then defined them a few lines down.

"Can't a man even talk to himself without being interrupted?" -Krull(1983)"Through vengence I was born. Through war I was trained. Through love I was found. Through death I was released. Through release I was given a purpose." -- Specter Phoenix"Programming == AWESOME the rest is just tools to accomplish it."END OF LINE

Nope. It's Deluxe Pacman. "Pac-Man" is a trademark of Namco or whomever (I researched it) so I avoid "Pac-Man" like the plague. You may be surprised to learn that "Pacman" however is not trademarked to any game company (there is a "Pacman" hat maker in Korea though, but that isn't related to games, so no problem).

The oddest thing I've ever seen has to be when a guy declared all his functions at the start of the program and then defined them a few lines down.

WHen I first used C, the common teaching was to declare all your functions at the start, your prototypes. The idea was that main was always the first function you seen, and any others could easily access your functions once they have been prototyped first.

These days I just declare the functions in a logical order so there are no problems, but that is the way C was originally meant to be done. My Deluxe Artillery Duel game has them all prototyped like that. And there is a certain bit of tidiness to it all I guess.

I still have much of my old BASIC code too, I had it all backed up and was browsing it today. Found some code I wrote for an artillery duel style game in QuickBASIC 4.5. The reason why I moved to C was that BASIC just wasn't fast enough for what I wanted at the time, not even compiled BASIC. It is now. I ran the original BASIC version and it was really fast. Also found some of my first experiments in C with artillery duel and it made me laugh as I had a tank shooting randomly all over and some of the shots were aimed straight up so they hit the player's tank again. I should make a video of them all, showing the progression just for fun. The original C code is scary to look at, the globals I used at the time will give you a heart attack!

Oh, if you want to relive the BASIC nostalgia, there is a modern version of QuickBASIC for windows. Runs old code and new, compiles etc. I should load up some of my old code on it and see how it runs now.

WHen I first used C, the common teaching was to declare all your functions at the start, your prototypes. The idea was that main was always the first function you seen, and any others could easily access your functions once they have been prototyped first.

I understand having a file of code like this, in fact this is how I prefer to do it when learning a new library so everything is in one file so I can see the code just by scrolling instead of jumping through files:

"Can't a man even talk to himself without being interrupted?" -Krull(1983)"Through vengence I was born. Through war I was trained. Through love I was found. Through death I was released. Through release I was given a purpose." -- Specter Phoenix"Programming == AWESOME the rest is just tools to accomplish it."END OF LINE

Well that was my code to stress my example. A series of active examples of my point is Lazyfoo.net's SDL2 tutorials. I have the code from lessons 12 and 17 and both have that similar format.

"Can't a man even talk to himself without being interrupted?" -Krull(1983)"Through vengence I was born. Through war I was trained. Through love I was found. Through death I was released. Through release I was given a purpose." -- Specter Phoenix"Programming == AWESOME the rest is just tools to accomplish it."END OF LINE

Always declaring takes the thinking out of it though. Especially as code changes and restructures. If you pre-declare all functions you never run into that "compile -> error -> predeclare -> compile" cycle. Modern languages take this guessing out of the equation for you. It can be a nuisance to run into it in C or C++.

I never had that problem. If I know a function will call one I am writing, I make certain it comes before it. I don't know, I just always done it that way and it's never been a problem. But I do understand the concept and would recommend new programmers do it properly.

Ever since I switched to D, I've basked in (and taken for granted) that there is no such thing as a forward declaration. Put any function, any class, anywhere you want. The order doesn't matter because compilers shouldn't be the dumbest thing in the toolchain.

Well, maybe forward declarations work for something else.

And the compile times. Good lord they're amazing once you hit a small-to-medium size project. No preprocessor pass. No includes. (Read: Modules. This thing they invented in what... the 80's?)

-----sig:“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

There's this school of thought (that I don't completely agree with) that putting all the functions into little table before they're defined it's like a table of contents in a book.

To be honest, I really like headers, though. It creates a well defined interface to a module. One of the things I don't like about, say, python, is that you can access everything once the module is imported.

There are a lots of things that I like in C in matters of mental discipline, but forcing the coder to sort his functions in the order "callee then caller" is really only for the compiler's benefit. An early processing of the C file would be enough for the compiler to determine which functions and variables the coder has ACTUALLY defined, and more accurately than guessing "Oh I don't know this function, it will probably return an integer".

Neil had a pretty good point: it makes a lot of sense to work in a language you're most comfortable in. When I get an idea for one of my games, I can implement it in c without learning some new language feature.

I started off with C when I was 13 or 14. I quickly jumped ship to C++ though, because the book I was reading at the time told me C++ was newer and offered more features than C. I have stuck with C++ ever since.

A lot of people bash C++ for being bloated; for sporting features which result in hard-to-read code; and for tacking on classes and polymorphism, which can often lead to further difficulties in readability and scope of code.

Personally, I think that you can accomplish the same things in either language. C++ is only bad if you abuse it and write bad code. In other words, I do not think that C++ is inherently bad, but it does lend itself to sloppier code. So I would agree that C forces you to be a better programmer, but it is ultimately up to the programmer whether or not their code is difficult to follow.

I have not done much in C or C++ recently. Instead I have focused mostly on JavaScript. JavaScript is incredibly flexible and convenient. I absolutely love it. It is much more forgiving than C or C++, which certainly can lead to sloppy code, but again, a good programmer will structure their code to be well organized in any language. As far as making games goes, I think I will stick with JavaScript, because with it I can share games without having to make binaries, which is super convenient. JavaScript is not as quick as C or C++, and it has its limitations, but for my purposes, it gets the job done better than the alternatives.

C doesn't force you to be a better programmer... C just forces you to be more verbose with your code (which is arguably worse). Of course, C++ has a lot of tricky features that are difficult to do right. Code that compiles will not work or won't even run for reasons that are completely oblivious to beginners and even some intermediates. C++ is a very difficult language to master. That makes it a poor language. C has an edge there because there's less to remember, however, C offers so few features that you tend to have to be very careful to write proper code. C++ can automate some of that. There's no real winner between them.

C's major advantage over C++ is probably unmangled symbols. This makes it much easier to invoke C code from almost any other language in the world. Whereas interoperability between C++ and other languages is more difficult (if not impossible) to achieve.

C++'s major advantage over C is probably RAII.

Dynamic, high-level languages are typically way ahead of both in terms of functionality and tersity. However, they typically are slower to some degree (which often doesn't matter unless you're writing a game that pushes the limits of today's hardware).