• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Code Formatting Nazi

  • Thread starter Deleted member 12930
  • Start date
yoda style if statements are beyond obnoxious. I'd rather deal with an infrequent accidental assignment than dealing with if(0 = blah) on a regular basis.
 
Whatsisname said:
yoda style if statements are beyond obnoxious. I'd rather deal with an infrequent accidental assignment than dealing with if(0 = blah) on a regular basis.
Click to expand...

C# will not compile with an assignment in the if clause (the vast majority of the time).
 
I had some cases where I found that useful, although not an if statement. In this case I don't happen to use the return value, but I still have the potential to use it inside the switch statement's scope. I've done this in conditionals for while loops and in if statements, there are certain cases where I think it's cleaner.

Code: 
void DX9Device::Present( void )
{
  switch ( HRESULT ret = mDXDevice->TestCooperativeLevel() )
  {
  case D3DERR_DEVICELOST:
  case D3DERR_DEVICENOTRESET:
    mDeviceLost = true;
    return;
  }

  if ( FAILED( mDXDevice->Present(0,0,0,0) ) )
    mDeviceLost = true;
}
 
It's old code, but I add spaces between all parenthesis now. It makes it so much easier to read and edit that code. Usually indenting refers to nesting scope. In the case of a switch statement, the cases aren't new scopes, they're all within the switch statement's scope. Same with identifiers like public:/private: on classes, I don't indent those because they aren't related to scope.

But again, all of this stuff is personal preference. I also rarely comment my code, rather have it comment itself. I only make notes for special cases, or things that are easy to over look, example being for_each with reverse iterators.

Code: 
void Core::StartupSystems( void )
{
  std::for_each( mSystems.begin(), mSystems.end(), std::mem_fun( &ISystem::vInit ) );

  mRouter.PostMsg( Msg::CoreInit );

  mInitialized = true;
}

void Core::GameLoop( void )
{
  while ( mRunning ) 
  {
    mTime.FrameTick();
    mInput.FrameTick();

    std::for_each( mSystems.begin(), mSystems.end(), std::mem_fun( &ISystem::vUpdate ) );

    mRouter.PostMsg( Msg::EndFrame );
  }
}

void Core::ShutdownSystems( void )
{
    // Note: This calls vDestroy in reverse order of vInit
  std::for_each( mSystems.rbegin(), mSystems.rend(), std::mem_fun( &ISystem::vDestroy ) );

  DeleteContainerReverse( mSystems );
}
 
Last edited:
That's some nice code.

Having small compact functions/methods that perform ONE AND ONLY ONE task is the best way to code.
 
Testing things for true and false in an if statement is silly. If it is bool or true when != 0 just use if(val) or the opposite if(!val).

It may not be clear, but I use assignment in if statements in C a lot. It is mostly to catch errors from function calls.
 
That's a private investigator, not a detective. I was thinking police force detective... but I guess the term is interchangeable

These threads never stay on topic...
 
Anyone get annoyed when there are layers and layers of objects and methods doing super simple tasks? I have to drill down the trail of 20 different methods/constructors before I get a sense of what's going on.
 
mastaBlasta said:
I've got the opposite problem. A bunch code for the application i'm working on is way OVERLY verbose. It's gone so far on trying to make it easy to read, that it has actually become more confusing.

Here's a sample. It's Ruby on Rails. The empty lines are actually there in the code.

Code: 
 ...

100 lines that could be compressed to less than 20. Things like if(some_Var == true) drive me crazy.

Sometimes being a nazi is not a good thing.

P.S.
BTW all the above code is supposed to do is built a new Object from the hash_IN parameter. Literally takes 2 lines.
Click to expand...

That mess has nothing to do with what is talked about here. Commenting on every obvious thing happening in the code would not be considered good formatting by any standard.

Honestly that looks like the code friends send me when they are doing their first programming assignment in school. Everything seems unclear so they add a comment above every line to either remind themselves what it does or ensure whoever is reading it understands (still they won't name variables in a sensible way etc).

Most of the time well formatted code with good naming on variables and methods does not need any comments, or very little. The first people who would complain about that are formatting nazis, so just opposite to what you assume. :)
 
cactus said:
Testing things for true and false in an if statement is silly. If it is bool or true when != 0 just use if(val) or the opposite if(!val).
Click to expand...
I'll do this only if val is of type bool. For other types, I use comparison operators even if the test is zero or not-zero.
 
Whatsisname said:
yoda style if statements are beyond obnoxious. I'd rather deal with an infrequent accidental assignment than dealing with if(0 = blah) on a regular basis.
Click to expand...
I use something like this in Perl fairly often,
Code: 
while(my $line = <FILE>) {
   ...
}
but my programs are generally all short, as well disposable after use.
 
mikeblas said:
I'll do this only if val is of type bool. For other types, I use comparison operators even if the test is zero or not-zero.
Click to expand...

This sounds like a good practice.

Sometimes the condition is conceptually a bitwise operation (ex. are any of the bits set?), in which case a comparison against decimal zero slightly confuses the intent for me.

In some languages there are built-in reduction operators, which will apply an operation to all the bits in a vector. Conceptually I find them the most intuitive representation of these types of tests. Not sure if these exist in the big languages.

I guess this is a pretty trivial concern.
 
Sometimes standards are trivial, and sometimes they're not. It's no surprise that students and less experienced developers rage against standards; they don't understand why they're necessary or helpful.

Software very quickly becomes complicated. AS it does, humans need tools for managing that complexity. Without the tools, complexity quickly outpaces the team's ability to manage and manipulate the code, and they end up beaching themselves against the weight of maintenance or bug fixing.

It might seem dumb to require "yoda style" comparisons, for instance. But once you've spent time, under pressure, trying to find a bug caused by a problem created by an inadvertent assignment in a conditional, you realize the practice is cheap insurance for avoiding that problem. When team members see code not written that way, it looks odd and they more carefully examine it -- they either fix it to normalize it or find a bug that was hiding.

I insist on explicit value comparisons because it's possible that an object has an implicit cast to bool. Reading the conditional makes the type clearer and the intent apparent.

Maybe you have some tools that behave better with styles and constructs, and that can influence your choices, too.

I don't think the arrangement of comments, whitespace, brackets, or parenthesis really matters much. You want to match the rest of the ambient standard on your team (unless you're prepared to completely change everything -- and you'll have to justify that work). The cost of doing that really isn't substantial, and it's not hard to get understanding on the dev team about it.

The value is there, sometimes. It's a matter of spending time on the right things, as usual.
 
jimmyb said:
In software development, how common is it to use linting tools?
Click to expand...

I don't think anyone uses actual lint anymore, because compilers are pretty good about warning you (if you configure them to). But static analysis tools are very popular.
 
It's common. Static code analysis tools exist and are popular and useful. The companies that make them don't go out of business. They're difficult to use, though, because they're prone to false alarms and only add value when the false alarms aren't so frequent (or so hard to manage) that they find enough real bugs to make them worthwhile to maintain.
 
I've found VS11's analyzer to be marginally useful and not cumbersome to use &#8212; a fairly sizable improvement over VS10's, at least in terms of ease of use. With respect to my codebases, the rate of false alarms has been fairly low, so the effort I've taken to produce 'clean' code, by the analyzer's definition, has been minimal. That said, I'm sure if I turned up all the knobs on it, I'd probably drown myself in the effort it would take to try and cover every little issue it turned up, but the default settings seem to strike a good balance there.
 
You must log in or register to reply here.
Back
Top