Timeline for Using compound statements ("{" ... "}" blocks) to enforce variable locality
Current License: CC BY-SA 3.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 11, 2015 at 12:53 | comment | added | JimmyB | @DocBrown That statement could be read as the suggestion "create as many methods as you possibly can", while the point is actually to create the right number of <elements>. SRP - The question is what exactly are the responsibilities for the given case? SRP seems to imply to have not more than one responsibility per element, but in fact each element should have exactly one (meaningful) responsibility, which poses some kind of upper limit on the number of elements to use. | |
| Nov 11, 2015 at 9:39 | vote | accept | wefwefa3 | ||
| Nov 12, 2015 at 11:51 | |||||
| Nov 10, 2015 at 22:18 | comment | added | Doc Brown | Honestly, but this term "method bloat" is IMHO a myth invented by people who are looking for excuses for not refactoring too big methods into smaller ones. | |
| Nov 10, 2015 at 21:11 | comment | added | BlueRaja - Danny Pflughoeft | @Bergi: Small methods do not bloat the class's API if they are private. They only bloat the file size... which large methods will also do. | |
| Nov 10, 2015 at 20:34 | comment | added | Dunk | @DavidArno - Having code that is easy to understand and is well tested doesn't do me much good if it doesn't work the way I need it to work. Thus, "It works" can never be removed from the #1 spot. But I totally understand how "it works" can be abused because that is the main reason used by people who just hack stuff together. Unfortunately, despite a desire to not have "it works" as #1, there is no other option. An ugly ball of mud that does what it is supposed to do is better than a beautifully architected, well-designed and easy-to-test masterpiece that can't do what it needs to do. | |
| Nov 10, 2015 at 20:06 | comment | added | David Arno | @Dunk, I used to think that way too. The problem is, if you treat "it works" as the top priority, you head off down a blind alley. I now realise that the top two attributes of code are 1, it's easy to understand and 2, it's easy to test (and by implication, is well tested via automated unit and integration tests). When well tested, easy to understand code breaks, it's easy to fix. When code that has "make it work" as it's priority breaks, it is often very hard to fix. The SRP is a key component of easy to test and understand code. | |
| Nov 10, 2015 at 19:29 | comment | added | Dunk | @DavidArno - it depends on your goal. If ease of understanding is a goal then lots of small classes is absolutely not the way to go. Having had to lead teams in the past when transitioning them from non-OO to OO development I can make that statement with 100% certainty of its truth. It just so happens that I have a list of desirable attributes in software. #1 - It works. #2 - It is easy to understand, are the top 2 choices. So while SRP may be an often preached mantra, that mantra is purely a naive view that at best is just a guideline. Certainly not worthy of using the word "Principle". | |
| Nov 10, 2015 at 17:59 | comment | added | Mindwin Remember Monica |
@Joe have to disagree. It is not tagged OOP, and it begins with "C-like". The fact is that a question tagged [carnivors] that mentions dogs does not immediately excludes felines or make it a dog question. Also the word method does not appear on the question body, just function. So it does not mention methods.
|
|
| Nov 10, 2015 at 17:43 | comment | added | Joe | @Mindwin the answer only mentions methods and not functions, making it OOP-specific | |
| Nov 10, 2015 at 17:41 | comment | added | Mindwin Remember Monica | @Joe the discussion in this comment thread was drifting too much into OOP. | |
| Nov 10, 2015 at 17:38 | comment | added | Joe |
@Mindwin ah true. I assumed it was about c++ as it has new but no public static. Some C-like languages (for example c itself) don't even have methods though.
|
|
| Nov 10, 2015 at 17:31 | comment | added | Mindwin Remember Monica | @Joe isn't the question language-independent. OP only mentions "C-like", every language that can have anonymous code blocks defining variable scope falls under this question. | |
| Nov 10, 2015 at 16:24 | comment | added | Joe | You shouldn't move your code into methods but functions instead if possible. Don't use C++ as if it were Java. | |
| Nov 10, 2015 at 16:22 | comment | added | Bergi | @DavidArno: Of course that's the goal, but it might not be (easily) possible. In such cases I prefer long methods over bloated classes. | |
| Nov 10, 2015 at 16:19 | comment | added | David Arno | @Bergi, you shouldn't have either. Lots of small classes, each with a single responsibility achieved via a small number of small methods is the winning combination. | |
| Nov 10, 2015 at 16:11 | comment | added | Bergi | This might provoke method bloat however. I prefer large methods over large classes. | |
| Nov 10, 2015 at 14:36 | comment | added | Jimmy Hoffa | + you get scope isolation, with a function the signature explicates the dependencies from the parent scope and handles them by value rather than by reference which adds greater isolation and protection between the scopes. | |
| Nov 10, 2015 at 14:19 | history | answered | Kilian Foth | CC BY-SA 3.0 |