Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 22 Aug 2001
Offline Last Active Yesterday, 10:00 PM

Posts I've Made

In Topic: Am I doing it all wrong?

Yesterday, 10:04 PM

Programming isn't about memorizing code. It's about understanding your tools and the ability to use them to figure out a solution to a problem. The code isn't "what" you're doing, it's "how" you're doing it. What you generally want to learn is the "what", because the "how" will come naturally if you know your tools.


In practice, you will usually solve each problem once and later go back to reuse or copy from your previous solution. Though it can make sense to force yourself to write it again and again a few times in some cases, until a particularly common algorithm (say quick sort, A*, etc.) isn't just that "mysterious chunk of code I wrote years ago and don't remember how it works". 


Copying from tutorials was probably not the point of writing them. Not only because it can be embarrassing to have code that calls "MyFunc" (yes, I've seen that kind of thing in production code), but because the point of that code is to illustrate and focus on a particular point or technique. That means there's usually little to no error handling and room for optimization, because that would obfuscate and distract from the actual subject matter. Also, unless you plan to build your whole program around a tutorial, it will rarely be something you can just drop into the rest of your code without plenty of adjustments. And then there's always the copyright question and what kind of use is permitted by the tutorial code's license.


So I'd move on to the next project. Learning and experience will happen naturally, unless you plan to wipe your memory or drink yourself silly after each programming session. While doing that, you will probably revisit your last project a lot anyway. For practice, resist the urge to copy/paste, if you just want to get it done, reuse away (just try not to copy comments or names that are nonsensical in the context of the new game).

In Topic: If-else coding style

01 July 2015 - 10:21 PM

The only reason I can think of why this could be called "misleading" is that at the very first superficial glance you see a function that return something, but only does so inside two blocks. So my very first impression would be "the main code path is missing a return". You'd have to look and check that it's indeed an if-else and not and if-if or other constructs.


That said, for easy constructs I usually go with ?: as well. If expressions are more clunky, I prefer early outs (ie. all error cases) at the top, so they are out of the way of what actually needs to be done without unnecessary nesting.


My personal pet peeve however is


if (condition)
    return true;
   return false;


This weird refusal to just use "return condition" or at least "return condition == true" (if you feel a need to be extra verbose) is somehow mostly seen with C-programmers. Probably still not used to bool being an actual type and basing it on "I tried BOOL func() {return flags & FLAG_X;} once and it failed, so I decided that returning a condition is always wrong in every way".

In Topic: Simulating Typing in C

10 June 2015 - 10:02 PM

Questioning the decision to learn C is a pure self defense mechanism, because:


a) on this forum alone, several people only learn C as a "first step" towards C++ due to the misconception that it makes any kind of sense


b) too many people starting with C pick up bad programming habits and never drop them after moving on to C++ which


c) leads to lots of frustration when your job mostly consists of debugging and/or reviewing code of "C first"-coworkers.


So, what isn't legitimate to question the motivation behind learning the programming equivalent of Latin (I doubt we're talking about C99 or even C11)? Unless C itself is the long term goal and the job involves embedded platforms and ancient compilers, the OP might very well be wasting time with a counter productive endeavor.

In Topic: Why didn't somebody tell me?

10 June 2015 - 09:42 PM

I find it much more confusing when floors in a building a numbered differently. When I can't tell if 1st floor is supposed to be ground floor or 2nd floor, I don't even care if I'm taking a lift or an elevator.

Speaking about errors resulting from bad hearing: every time I read "he should of" or "I would of" it just makes me die a little inside. In not a single parallel universe is that arrangement of words anything but completely nonsensical, yet it's probably just a matter of time before it ends up in a dictionary. After all, people not understanding what "literally" means has already resulted in literally being basically defined as "may also mean its exact opposite".


From there we get to "effect" and "affect". In fact, I remember a warning label on one of our card dispensers, that said something like "Warning: not using the correct type of cards as specified in the manual may effect the proper functioning of the device". So, basically we're saying "if it's not working, try not doing what the manual tells you and it might just fix it". Of course, nobody understood why that label made me laugh and why I asked if they're actually serious.

In Topic: Simulating Typing in C

06 June 2015 - 10:59 PM

Well, while we're already (incorrectly) nitpicking the example (std::string has both size() and length()... length because it makes more sense conceptually and size for consistency with other containers)...
void print(std::string text)
This will rather pointlessly create a copy of the string, 9 out of 10 times you want to pass it as const reference:
void print(const std::string& text)
for(int i=0; i<text.length(); i++)
Generally the rule of thumb is to avoid calling functions in your end condition. Since you didn't make the string const, the compiler might end up evaluation length on every iteration. Before C++11, an implementation could actually internally call strlen and end up pointlessly iteration the whole string to count characters on every iteration of your loop.
"Complex" loop conditions that won't change during the iteration should be evaluated once before the loop:
const size_t length = text.length();
for (int i = 0; i < length; ++i)
In this case however, string follows the usual container conventions, so in C++11, just use a range based for loop.
for (char c : text)