> Alright, I'll bite: ?what is the issue you see with having a boolean parameter? To me, the thought process is actually the same for any parameter, but booleans stick out as particularly annoying. For any parameter there are essentially two use-cases when the method or function is called - a literal value or an opaque value passed onward from somewhere else (which in turn may be a parameter, some kind of calculation, the result of another function, etc.)
The classic minimal boolean parameter scenario is something such as switchLight(boolean on_off). You see this kind of thing a lot in embedded programming, even when the boolean value is always literal and the use of two separate implicit methods would be both less ambiguous and more efficient: switchLightOn() and switchLightOff(), for example. Leo Brodie, and by extension Charles Moore who Leo quotes a lot, discusses this kind of thing and a lot of other technical/philosophical concerns in the book Thinking FORTH. On Jun 22, 2023, at 3:24 PM, Mark Levison <mark@...> wrote: > She would like a book(s) that will help learn to be a good programmer. Many of the best programmers I know got that way by exposure to different languages and different paradigms. As well as the above mentioned Thinking FORTH I would recommend Smalltalk Best Practice Patterns by Kent Beck, and almost anything you can find about LISP or APL. All of these have something different to offer which can shed a light on how best to use the language and tools you have available. And also don't forget the classic language-independent writing such as Jon Bentley's Programming Pearls books. If she?really wants to take it to the next level, then some time working with assembly language will help you develop that 'gut feeling' for when a solution is bloated or too complex for its own good. These days I recommend Risc-V as a good assembly language to start with. Frank. |