is following method bad code design?
public void amethodthatdoeshorribleirreversibledamageiftheuserisntcareful(boolean doaction) { if (!doaction) return; //rest of dangerous , irreversible method code } the method (as aptly named) performs dangerous action can not reversed.
is bad practice put boolean flag parameter force them pay closer attention when calling method?
a benefit having parameter caller alerts user perform dangerous , unchangeable action , prompts them if sure want it. use result of the prompt parameter passed in.
would such method parameter fulfill purpose or waste of time (and worse cluttering method parameter list)?
this wrong on many levels:
- if think method horrible, why did put source code in first place?!
- if figured such method exists, , can called; think adding boolean argument prevent calling method?!
- to contrary: "readability" or "user experience" point of view, making things worse: add parameter has absolutely no value. calling method true. thing achieve people trained call methods without further thinking arguments provide.
- good interfaces should make easy right thing; , hard wrong thing.
the final point leads only acceptable answer here: only call method after real user (the person running application) has been warned, , confirmed "yes, yes, yes, it" took place. , coding perspective, achieve naming ...
in other words: should distinguish between fellow coworkers , end users. coworkers have full access source code anyway. additional booleans won't stop them doing wrong thing. prevents them doing wrong things are: easy-to-read-and-understand code , education "team policies" , "application design".
if developers understand method about; , doing; careful.
the other group, end users: said - if want "horrible" happen; , warned them, , still want - make call.
Comments
Post a Comment