How about #define is_true(tf) ((uintptr_t)0 != (uintptr_t)(tf))
-----Ursprüngliche Nachricht----- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Don V Nielsen Gesendet: Dienstag, 13. August 2019 22:42 An: SQLite mailing list <sqlite-users@mailinglists.sqlite.org> Betreff: [EXTERNAL] Re: [sqlite] Programming methodology (was DEF CON (wasL A license plate of NULL)) If I were to have coded that junk (and I do see it too many times to count), I would have coded it even junkier, as in bool is_true (bool tf) { if (tf == true) return true; else return false; } If it's single statement following an if and that statement isn't beyond 80 characters, I will code it as a single line bool is_true (bool tf) { if (tf == true) { return true;} return false; } I would normally comment the method with something like // SWEET MOTHER OF MOSES, WHO CODED THIS???? // But since it is existing code, I have chosen not to touch it and kick the can down the road. // I don't want to be responsible for retesting the 97 million functions that actually employ // this piece of On Tue, Aug 13, 2019 at 2:52 PM Keith Medcalf <kmedc...@dessus.com> wrote: > > On Tuesday, 13 August, 2019 13:17, Jose Isaias Cabrera > <jic...@outlook.com> > wrote: > > >James K. Lowden, on Tuesday, August 13, 2019 12:31 PM, wrote... > > >> On Mon, 12 Aug 2019 14:14:08 -0600 "Keith Medcalf", on > > >>> Perhaps I am just lazy but I see no point in engaging in extra > >>> work for no advantage > > >> bool > >> is_true (bool tf) { > >> if (tf == true) { > >> return true; > >> } > >> return false; > >> } > > >Completely, completely off the subject, but since I see this code > >here, and I have always wanted to ask this... > > >When I started programming, back in 1982, my teachers taught me to > >match my end bracket to the same column where the beginning bracket > >was. And they explained the whole theory behind it, which I think > >it's true, to today. For example the above code, I would have > >written it this way:' > > >bool is_true (bool tf) > >{ > > if (tf == true) > > { > > return true; > > } > > return false; > >} > > >Where, the brackets, begins/ends, would match the same column. When > >did this ideology change? I see all of you smart programmers using > >this non-column matching behavior, and I ask myself why? Thoughts? > >Or not. :-) Thanks. > > It is a matter of taste I suppose, since there are numerous bits of > software which can prettify various languages to a number of different > formats. The primary reason I have heard putting the opening brace on > the same line is that it takes less space on the screen, and after all > we can only afford 5 line monitors, am-I-right? > > Personally I like the format where the braces line up with the start > of the statement that they belong to and appear on a line by > themselves, and the contained block is indented. Then again I can > afford an absolutely humongous monitor that can display about 50 lines per > page. > > Some people are severely allergic to white-space and so eliminate > every non-required space/tab character all line-feeds/carriage-returns > that are not within a quoted string and write their software as one > big never-ending single line of code 40 miles long. > > There are also some wierd formats that some seem to like as well where > they half-indent the braces and other such malarky. > > It is all a matter of taste and what you can see easily. I also tend > to use blocks around code that technically does not need them (as in > the above > example) because it makes it easier to see what is going on -- the > visual appearance matches the parse tree generated by the compiler as it were. > Only the folks that do not use blocks obviously are struck by decades > old code editing errors that they did not intend (and we have had a > few of those in the last couple of years where the "visual depiction" > did not match the "computer generated parse tree" ... > > -- > The fact that there's a Highway to Hell but only a Stairway to Heaven > says a lot about anticipated traffic volume. > > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users ___________________________________________ Gunter Hick | Software Engineer | Scientific Games International GmbH | Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 1 80100 - 0 May be privileged. May be confidential. Please delete if not the addressee. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
