Timeline for "Have a safe trip"… or not, depending on four conditions
Current License: CC BY-SA 3.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 11, 2016 at 11:40 | history | edited | Adriano Repetti | CC BY-SA 3.0 |
added 417 characters in body
|
| Feb 10, 2016 at 19:51 | comment | added | Adriano Repetti | It's not such oop purist topic if you're using an OOP language like Java (where it's the only reasonable paradigm). However do not confuse "more often than not not" with always. Yes, SOMETIMES it's reasonable. All the other times we are just lazy to proper design our classes. | |
| Feb 10, 2016 at 17:08 | comment | added | k_rollo | Nevertheless, I appreciate the inputs collected in this thread. The initial question has been promptly addressed and to avoid further thread-jacking, I now leave the fate of this thread to the mods/admins. Thank you all for your time. | |
| Feb 10, 2016 at 17:08 | comment | added | k_rollo | "Utility/helper classes are more often than not a big code smell." - This got me interested into reading about the matter here and here. It seems there's no unanimous take on this with several commenters even attributing it to "oo purism". Seeing the ProgrammersExchange thread was also closed for "possibly soliciting debate/arguments", it appears it's more of an opinionated discussion than a factual one. | |
| Feb 10, 2016 at 13:05 | comment | added | Adriano Repetti | @oopexpert I agree, I edited my answer after OP posted his own because there was (little) bit more context. Better review would need much more surrounding code! | |
| Feb 10, 2016 at 12:18 | comment | added | oopexpert | Technically there are a lot of solutions. You put the code on the semantic trial. Thats what I would do as well because simply make the code more compact is only sometimes the solution but not always. As we see only little code with some names we cannot judge it in the whole context it will be used. But as the names are very expressive we can get a vague idea whats the purpose. So combining things that belong together and separating things that do not are things on the semantic level that should drive your code. That was clearly pointed out here. | |
| Feb 10, 2016 at 10:53 | history | edited | Adriano Repetti | CC BY-SA 3.0 |
added 1443 characters in body
|
| Feb 10, 2016 at 7:53 | history | edited | Adriano Repetti | CC BY-SA 3.0 |
added 425 characters in body
|
| Feb 10, 2016 at 7:48 | comment | added | Adriano Repetti | @silver I see they're local variables, I'd still move them to their own function if they're even slightly more than trivial. doPost() method is doing many things and you need to read it all to understand what it is doing. That's usually a pretty bad thing, in ideal world to understand such high level feature I would read just 10~20 lines of code (less is better) because in two seconds I can get an overview of what should happen. Is it that method too long to post it here (you may get a better review)? Then it probably needs to be refactored... | |
| Feb 10, 2016 at 2:21 | comment | added | k_rollo |
Hello, Zesar is quite right about "local vars in the method-context". The code is actually inside a Servlet's doPost(). But thank you Adriano as well for the bullet points, I actually liked the second one - makes sense. Upvoted. :)
|
|
| S Feb 9, 2016 at 23:26 | history | edited | SirPython | CC BY-SA 3.0 |
please *always* use brackets around an if block, failing to do so introduces errors and actively harms readability
|
| S Feb 9, 2016 at 23:26 | history | suggested | cat | CC BY-SA 3.0 |
please *always* use brackets around an if block, failing to do so introduces errors and actively harms readability
|
| Feb 9, 2016 at 22:57 | review | Suggested edits | |||
| S Feb 9, 2016 at 23:26 | |||||
| Feb 9, 2016 at 14:44 | comment | added | Adriano Repetti | Mine too, I'd use functions for that! We may need little bit more context from OP. | |
| Feb 9, 2016 at 14:39 | comment | added | Zesar | I'm all with you on this. as wrote, if the logicals are members then maybe you would like them to have accessors. My understanding was that the scope of the problem was "how to clean the code up within a method/function", ie. local vars in the method-context. | |
| Feb 9, 2016 at 14:35 | history | edited | Adriano Repetti | CC BY-SA 3.0 |
added 194 characters in body
|
| Feb 9, 2016 at 14:31 | comment | added | Adriano Repetti | @Zesar absolutely no need to be accessible outside their class. 80% (arbitrary aleatory number) of an object methods are private/protected. They're implementation details with the only purpose to make your code easier to read. Do you have a long complex logical condition? Split it and it won't be an issue any more. If they're also reusable because same condition(s) is also checked elsewhere then it's another bonus. | |
| Feb 9, 2016 at 14:11 | comment | added | Zesar | This would only be resonable if canBookTrip, isExistingDestination, isAccountInformationValid and so on are supposed to be accessible from outside the object or maybe if they are members. if these are only variables within a member-function this is overkill. | |
| Feb 9, 2016 at 13:28 | history | answered | Adriano Repetti | CC BY-SA 3.0 |