• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
cozzie

Unity
if statement in for loop, brackets needed?

32 posts in this topic

Hi,

 

Just a simple question, with a nice opportunity to clean my code :)

I'm not sure when I need to use brackets in a for loop, depending on the code that needs to be executed for each iteration.

 

Example, I have:

 

for(mat=0;mat<mNrMaterials;++mat) 
{	
	if(materials[mat]) ++mEffect[fx].nrMaterials; 
}

Would the result be the same if I use:

 

for(mat=0;mat<mNrMaterials;++mat) 
	if(materials[mat]) ++mEffect[fx].nrMaterials; 

I know that I can leave the brackets out if I just have one line of code for each iteration, like:

 

for(int i=0;i<5;++i)
  something[i] = i*2;

Anyone?

0

Share this post


Link to post
Share on other sites

I use unbraced forks only for if-wrapped return, continue, break, and throw statements, because those don't have "else" forks; any subsequent code is an "else" after that.

 

But, I also tend to write very dense loops, frequently without an actual body, so sometimes the body of my loops ends up being a single semicolon, ie

for(int i=0, j=arraylength-1; i<j; array[j--]=array[i++]) ;

 

And that just becomes more unreadable when I waste essentially blank lines putting empty braces on the following couple lines.

0

Share this post


Link to post
Share on other sites

I have settled on using curly braces when there is more than one line in the body


I'll throw another vote in this pile. I use no curly braces when the statement does not have its own block scope, and when it can fit cleanly on one line. If it requires two, I put braces on it. Since I put if statements on a separate line from what is executed conditionally, then that means that that is enclosed in braces, too. I do agree that extra braces reduces the possibility of human error; I may consider doing it all the time at a later point. In effect, I use no braces when the block looks concise enough that it can be readily understood as being the sole statement of the block, and that no more statements would be added. If I have to debug, I add braces, output the values, then remove braces when I remove the output code.

In my mind, where I parse the source linearly, a no-brace if statement gives me an explicit measure of what the conditional encompasses, and it looks aesthetically pleasing to my eye at how the simple things appear very obviously simple.

However, once I must team up with someone that is prone to human error in these kinds of places, I'd probably opt to ensure that we aren't each other's downfall.
1

Share this post


Link to post
Share on other sites
My rule for [tt]if[/tt] and brackets is if there is an [tt]else[/tt] then brackets need to go on both halves and an [tt]if[/tt] containing an [tt]if[/tt] or a loop statement requires brackets on the outermost [tt]if[/tt]. So
// fine
if (a) foo;

if (a) if (b) foo; // no good instead do:
if (a) {
  if (b) foo;
}

if (a) for (;;); // also bad, instead:
if (a) {
  for (;;);
}

// fine
if (a) {
  foo;
} else {
  bar;
}
Similarly, for loop statements a loop containing a loop or an if requires brackets.
0

Share this post


Link to post
Share on other sites

My rule is to ALWAYS use braces no matter how little code is inside them.  It is just a more secure way of coding.  There are already resons mentioned above.  But my personal favorite was a senior coder (who was also a complete fuckwit) I worked with a couple of years ago made it a rule that single lines should not have brackets. He also had a list of debug macros that he used.

Instead of disableing the macros when he did a release he just did a grep and replace to comment out all the macros. 

 

So we ended up with:

<get some data>

if(<a problem with data>)  //<commented out macro here>

 

<do processing on the data>
 

 

This pattern by the way he had used in several hundred places throughout the project.  Then he blamed the rest of us for it not working even though we had told him his code was shocking during every single code review.

1

Share this post


Link to post
Share on other sites

For me brackets or not seems just like a matter of style. If there are none and you add a second line, surely you should know you also need to add brackets.

But putting the body on the same line as the if is annoying if you happen to want to put a breakpoint there or single step the if, as you cant easily see then if the body was actually run.

Edited by wintertime
0

Share this post


Link to post
Share on other sites

There is only one case where I feel its acceptable to omit braces.

It's for one line tests with simple expressions like this:

 

if(!some_object) some_object = new SomeClass();

 

If you want to add a second line, you have to start with adding a line break, and at that point, it's very obvious that you need to add brackets too. 

Even with stress levels high.

 

 

For me brackets or not seems just like a matter of style. If there are none and you add a second line, surely you should know you also need to add brackets.

Well, the only protection against idiotic programmers is better hiring and firing decisions. Bracketing conventions won't do.

 

Easy to say until that day you sit there with the deadline looming over your head, with stress levels at max, trying to fix that last show stopper bug.

The "just going to add some print out" happens very easily... And you really dont want to spend even 5 minutes with something like that, totally breaks your flow.

 

Clean and consistent code = less bugs and frustration

always.

Edited by Olof Hedman
1

Share this post


Link to post
Share on other sites

I have spent decades coding in C-like languages.  I have seen a significantly disproportionate number of software error arising from not using braces in control statements than from (almost) any other construct.  The 'other construct' is mistaking '=' for '==' in comparisons, but that's less easily avoided.

 

The problem doesn't come from writing new code.  The problem comes from maintaining existing code.  Remember that all code is existing code the moment you're finished typing it.

 

I have worked on projects in which the formalized and enforced coding style dictates that a single line in a control construct should never use braces, likely in an attempt to save on electrons.  With one significant exception, every such project has had a higher bug rate and higher maintenance cost.  The one exception has a very large automated test suite (which takes hours to run) but is under very restricted maintenance, since it's a standard library with strongly defined functionality and wide distribution.

 

There are, of course, strong opinions on the aesthetic of brace usage in coding style.  Such opinions are significantly more important than practical issues such as minimizing maintenance costs or maximizing software reliability.

2

Share this post


Link to post
Share on other sites

Ho boy, a bracketing convention debate.

 

My advice is to always use braces.

 

In practice, I add braces only when I need them, but don't remove them when the need disappears, such as if debug code is removed or the code is reformatted.

 

Also, I always use a newline after all if statements and non-empty loops. Empty loops get a pair of braces on the same line. 

0

Share this post


Link to post
Share on other sites

Empty loops get a pair of braces on the same line.


That's an interesting idea. I use empty braces on the same line for an empty function or class definition. My empty loops look like this:
while(*(src++) = *(dst++))

        ;

 

I guess I just feel like loop bodies should start on the next line, no matter what. I'm also strongly against semi-colon on the same line to prevent things like this:
for(;;);
{
//Why am I not executed as expected?
}

Edited by Ectara
0

Share this post


Link to post
Share on other sites

I have programmed in C-like languages for aboud 20 years now, 13 of them professionally. I have never ever seen a problem with the use of braces.

 

I find that hard to belive that in 13 years of proffesional coding you have never once found a bug written by either you or by someone else that involved incorrect use of braces.

 

1

Share this post


Link to post
Share on other sites


I have programmed in C-like languages for aboud 20 years now, 13 of them professionally. I have never ever seen a problem with the use of braces.

 
I find that hard to belive that in 13 years of proffesional coding you have never once found a bug written by either you or by someone else that involved incorrect use of braces.


I'm telling you, I can't remember one. As I said, emacs makes it very obvious if you are writing at the wrong level of indentation. Also, perhaps our testing procedures are good at catching that type of mistake.
0

Share this post


Link to post
Share on other sites

I have programmed in C-like languages for aboud 20 years now, 13 of them professionally. I have never ever seen a problem with the use of braces. So I don't think it's that important.

I have. Once. (though I've got much less experience than you). It was in the FFmpeg source code. Indentation levels indicated the else statement was part of a different if block, but actual control flow was otherwise. The actual logic ended up being correct, but anyone reading the code was likely to misread the code (like I did initially) because of incorrect indentation levels and a complete lack of braces. That was a fun day.

0

Share this post


Link to post
Share on other sites

I have programmed in C-like languages for aboud 20 years now, 13 of them professionally. I have never ever seen a problem with the use of braces. So I don't think it's that important.It could also depend on what editor you use. Emacs understands the level of indentation you are at, so when you go to add a second line to the `then' clause, the cursor will go to a place where it's obvious that you need braces.I agree with everyone that the most clear style should be used. So use whatever you think is more clear.


I agree with this, after (is it 15 now?) years of coding i have never seen anyone accidentally add code to a statement without braces and failing to add them. Part of it might be because I have mostly worked with coding styles that dictate braces on new lines, and ide/editor support, as you say.
0

Share this post


Link to post
Share on other sites

Empty loops get a pair of braces on the same line.


That's an interesting idea. I use empty braces on the same line for an empty function or class definition. My empty loops look like this:
while(*(src++) = *(dst++))

        ;

 

I guess I just feel like loop bodies should start on the next line, no matter what. I'm also strongly against semi-colon on the same line to prevent things like this:
for(;;);
{
//Why am I not executed as expected?
}

It's nice to have the same convention for all blocks, including both functions and loops. And {} is much more noticeable than ;, in part because one doens't normally put {} after a statement otherwise, and in part because it actually means something different for functions, so we're trained to notice it.

1

Share this post


Link to post
Share on other sites

As I said, emacs makes it very obvious if you are writing at the wrong level of indentation.

To my mind this is 90% of it. If you aren't using an editor that is highly aware of syntax (vim, emacs, sublime, etc), then informal code conventions are going to trip you up.

I really don't know why so many programmers adamantly continue to use inferior tools. For example:
[source]$ g++ -Wall test.cpp[/source]
versus:
[source]$ clang++ test.cpp
test.cpp:5:12: warning: if statement has empty body [-Wempty-body]
if (1 < 2);
          ^
test.cpp:5:12: note: put the semicolon on a separate line to silence this warning[/source]

0

Share this post


Link to post
Share on other sites

But a syntax-aware editor is not going to catch the valid use of valid syntax.

All of my primary editors fix the incorrect indentation there - it doesn't make the bug go away, but it makes it damn easy to spot during code reviews.
 

Code is meant to be read, after all, not written, and that includes when looking at diffs during code reviews and online in VCS webviews, where building in a context-sensitive C++ front-end is just not going to cut it.

Then auto-format all your code using a pre-checkin hook on your version control.

 

You should probably be doing this anyway, to deal with funky whitespace issues.
 

Oh, and condemning tools as inferior because you do not know how to use them says less about the tools.

The point isn't that I don't know how to use gcc (I do), the problem is that it's off by default, and many users don't know how to turn it on. The whole idea that -Wall does not, in fact, turn on *all* warnings, is a bit of a non sequitur.

1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • By NajeNDa
      Hi there,
      I am a game programmer (C#/C++) who is looking for a project to join. I am computer science engineer plus Master Degree in Game Development, currently working in one the most renown mobile games company (2 years academic experience, 1 year working experience).
      I have developed several prototypes or even games almost ready to release, but I always lack of artists, so I am looking for a project already set up or few artist to begin working in something.
      My preferences are:
      Unity or Unreal Engine 4 based project (UE4 prefered) PC/Console game prefered but mobile is acceptable Not interested in VR Serious team with almost all the roles filled or pretending to be filled 3D project prefered over Sprites Guaranteed 7 work hours per week, Crunch 20 work hours per week  European team (if timezone is not a problem for you, so it is not for me) I am not looking for any kind of money income from games neither the team, I want to do this as a hobby and a way to improve my skills.
      Cheers
    • By OPNeonGames
      SumiKen : Ink Blade Samurai is released! Download and leave a review to help support the game!
      Download here for free : https://play.google.com/store/apps/details?id=com.OPNeon.SumiKen&hl=en

      ★★★★★ - "Just get it it's the best runner!" - Icatsasha
      ★★★★★ - "Great game, wonderful art! Super addictive!" - EZk1ll 
      A casual samurai runner game with seven samurai and beautiful mountain paintings. Join Sumi and his samurai companions on this epic path to slash & dash through endless hordes of enemy lines. Beware of the enemy blades as a single blow from the sword blade will end it all. Will you be turned into faded ink? Or will you train and become a samurai legend?
       
    • By OPNeonGames
      Hey guys, posting my work in progress for Macho Cat here. 

      A very early prototype for Macho Cat. Everything is just placeholder for now
      What is Macho Cat?
      A silly little game where you scrub the macho cat with random objects found in trash and junkyard to please him
      Gameplay feature?
      -Cat scrubbin, lots of scrubbin
      -Unlock moar objects in junkyard 
      -Funny, silly and easy
      When will the game release?
      December 2017 (estimate)
      Interested to Beta test?
      opneongame@gmail.com
    • By MCKillerZ1
      UNITY ENGINE
      IN SEARCH FOR MEMBERS
       
      Hey there. I am currently looking for at least 4 members ( for now ) to join me in making games together.
      Sure, I'm still a student ( 17 years old ) but this is what I wish to achieve in the future.
       
      My goal is simple:
      :- Create my own game development team consisting of 5 members total.
      :- Work together as a team, and also learn game related things together.
      :- Successfully finish a simple game, and upload it to any source ( Google Play, Steam, Origin, etc... )
      :- Gain popularity as a team over the time.
       
      My role in the team is the producer or manager, or maybe the leader.
      I do have talent regarding to creating games. My main ability is creating 3D Models via SketchUp, and I've had experience doing it for about 2-3 years.
      I did learn a bit of programming, but I only understand the basics of it. I can't really make a functioning program.
      Currently, I'm learning the basics of making music using FL Studio 12, and I will learn basic animation, level design and character modelling in the future.
       
      Requirements To Join:
      1. Good English communicating skills.
      2. Always online whenever needed.
      3. Good internet connection/speed.
      4. Have a decent computer/laptop.
      5. At least knows the basics of game development related topics.
      6. Have a good camera and a set of headphones with mic, or just regular mic ( needed in the future ).
       
      Roles Available:
      1. Programmer - Main language is C#, but can also use Java ( I recommend C# ).
      2. Music Producer - Can create music according to the game's settings, and also create sounds.
      3. Animator - Can do decent animation of characters, vehicles and more.
      4. Graphics Designer - Able to do colour schemes, 2D sprites and more.
       
      Send me a message if interested.
       
       
    • By OPNeonGames
      Hey guys, posting my work in progress for Macho Cat here. 

      A very early prototype for Macho Cat. Everything is just placeholder for now
      What is Macho Cat?
      A silly little game where you scrub the macho cat with random objects found in trash and junkyard to please him
      Gameplay feature?
      -Cat scrubbin, lots of scrubbin
      -Unlock moar objects in junkyard 
      -Funny, silly and easy
      When will the game release?
      December 2017 (estimate)
      Interested to Beta test?
      opneongame@gmail.com
  • Popular Now