Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mimsy!umd5!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: Writing readable code Message-ID: <6057@brl-smoke.ARPA> Date: Sun, 5-Jul-87 15:47:37 EDT Article-I.D.: brl-smok.6057 Posted: Sun Jul 5 15:47:37 1987 Date-Received: Sun, 5-Jul-87 22:41:54 EDT References: <13008@topaz.rutgers.edu> <1941@zeus.TEK.COM> <849@tjalk.cs.vu.nl> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB)) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 27 Let me explain by example why if ( bool_expr == TRUE ) is dangerous (it should be obvious why it's redundant), so that if ( bool_expr ) should be preferred. There is no corresponding problem in C with if ( bool_expr == FALSE ) although I would recommend if ( !bool_expr ) instead. As other have remarked, the proper use for symbolic constants TRUE and FALSE is as values to be assigned to variables (or function returns) that are considered to be inherently Boolean in nature. (Actually, I so strongly consider treating Boolean objects as inherent primitive types to be important that my own definitions are lower-case, to appear just like language keywords.) EXAMPLE: The original UNIX System V Release 2.0 definitions in were #define feof(p) ((p)->_flag & _IOEOF) #define ferror(p) ((p)->_flag & _IOERR) These are supposed to be treated as Boolean expressions, but their TRUE values are NOT 1. In my version of I changed these to #define feof(p) (((p)->_flag & _IOEOF) != 0) #define ferror(p) (((p)->_flag & _IOERR) != 0) for safety's sake.