Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Jul 2003
Offline Last Active Today, 05:43 AM

Posts I've Made

In Topic: Windows 10 Game Programming

18 August 2015 - 01:17 PM

There's a donut shop near where I live that makes exactly one type of donut.  Despite no choices people flock from afar to enjoy them.

Sometimes just having one option is the easiest!

In Topic: Windows 10 Game Programming

18 August 2015 - 12:15 PM

Thanks Ravyne.  The little hat operators, and their ilk, do rub me the wrong way.  I will definitely grab that library and give it a spin.

In Topic: Windows 10 Game Programming

18 August 2015 - 12:07 PM

Thanks for the reply, SmkViper.  The examples I'm exploring with the WinRT flow are clearer than the venerable Win32 model.  To boot, the new Visual Studio 2015 Community hearkens back to the day when Studio releases actually included all the nifty built-in tools.  I was kinda bummed in VS 2010-2013 that for things like IDE extension you needed to purchase the $200+ version.  I just kick around Windows programming as an amateur / hobbyist and that price tag was certainly a barrier to entry.  Now I can march along, learn a little about what XAML is and the integrated GUI developer (that AFAIK only existed in .NET in recent releases of VS).

I know lots of people tend to have strong opinions about OS, particularly Windows, but I am impressed with where they are headed and what they offer.  I'm tempted to get an Xbox One merely to trying streaming to the PC.

In Topic: Code appearance, is it really important?

14 January 2015 - 11:02 AM

Mind you, this is my personal observations and speculation from my own hobbyist projects; not the result of scientific studies. I'm not a AAA developer working in the industry, nor do I have a PHD in computer science.


Sorry to be a little off topic, but you do a disservice to yourself.  Experience is a huge asset.  Your accumulated knowledge has benefited this site quite often.

Consider this scenario.  You seek medical surgery and you have a choice:  (1) select a doctor who did nothing but read books and study theory but never did any medical procedure, (2) or one who learned no formal theory, yet learned by watching other doctors and performing surgeries under their watchful eye?

Obviously, to be the best doctor you want both and that's why there is such a strong requirement for medical school and residency.  Doctors need a strong competency in theory and working memory, because these areas stimulate different parts of the brain.  (Also, consider that doctors can't just practice surgery whenever they want;  they can only operate on maladies that people actually present them.  A computer programmer can simply learn whatever they want, whenever they want.)


To dovetail back to the OP and to echo an expression that GDNET continuously expounds.  You learn programming by programming.  Sure, take some suggestions, read books and articles, and maybe even get that PhD to get a deep, specialized knowledge of computers.  But make an effort to dig in and do it. Style seems to be such a simple question to ask yet its answer touches upon many root aspects of programming.

In Topic: Code appearance, is it really important?

13 January 2015 - 02:59 PM

That a computer language even exists is testament to the benefits of clarity.  We could all be doing punch cards or pure assembler programming if this aspect made no difference.

Some standouts:

  • Once you establish your style, stick with it.
  • Keep consistent tabs for each new lexical scope.
  • Organize headers / routines so public, protected, private, etc. functions appear in the same order.
  • When possible, keep functions relatively small -- no more than a page at a time.  If I start to see spaghetti code I build hierarchy to replace strands of code.  It's a good way to establish concepts and start to see patterns.  Spaghetti code is hard to understand especially when you're constantly scrolling up and down within the same function.
  • Give descriptive names to your functions, variables, files, etc.

You'll eventually write some code that you may return to later.  With a clean, consistent style you'll get to the source of your bug when you find things where you expect to see them.