good to apply:
* Don't write a == CONST. Instead, write CONST == a. Or, more generally
(in C like languages): Avoid putting an lvalue on the left-hand side of
an == comparison. (For consistancy, I try to avoid lvalues on the left-
hand side of any comparison---but == is the most notorious.)
(An "lvalue" is a value that can safely go on the left side of an
"=" assignment, of course. (^&)
* Do not write
if( !condition )
return;
other_thing;
return;
(See page 18 of K&P's _The Elements of Programming Style_.)
Instead, it is better to just write:
if( condition )
other_thing;
return;
There are times when sacrificing structured programming (e.g., via
multiple return statements) is okay. But, here, there is no apparent
gain---indeed, there seems only loss---in the non-structured code.
git-svn-id: svn+ssh://svn.code.sf.net/p/freeglut/code/trunk/freeglut/freeglut@308
7f0cb862-5218-0410-a997-
914c9d46530a
*/
static void fghVisibility( int status )
{
- FGCBVisibility vis;
- int glut_status;
+ int glut_status = GLUT_VISIBLE;
freeglut_assert_ready;
freeglut_return_if_fail( fgStructure.Window );
- vis = FETCH_WCB( ( *( fgStructure.Window ) ), Visibility );
- freeglut_return_if_fail( vis );
- if( status == GLUT_HIDDEN || status == GLUT_FULLY_COVERED )
+ if( ( GLUT_HIDDEN == status ) || ( GLUT_FULLY_COVERED == status ) )
glut_status = GLUT_NOT_VISIBLE;
- else
- glut_status = GLUT_VISIBLE;
- vis( glut_status );
+ INVOKE_WCB( *( fgStructure.Window ), Visibility, ( glut_status ) );
}
void FGAPIENTRY glutVisibilityFunc( void (* callback)( int ) )
/* A. Donev: Destruction callback for menus */
void FGAPIENTRY glutMenuDestroyFunc( void (* callback)( void ) )
{
- if( fgStructure.Menu == NULL )
- return;
- fgStructure.Menu->Destroy = callback;
+ if( fgStructure.Menu )
+ fgStructure.Menu->Destroy = callback;
}
/*