Timeline for Should I add redundant code now just in case it may be needed in the future?
Current License: CC BY-SA 3.0
56 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 12, 2017 at 7:31 | history | edited | CommunityBot |
replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
|
|
| Jun 4, 2016 at 23:24 | comment | added | Kyralessa |
@Taemyr, but the same principle holds true. Though looking more closely at the code, it looks problematic from other points of view. Since rows isn't passed with ref, initializing it if it's null won't have any effect on that argument when the method returns. The method should probably act on the thing containing the List<CalendarRow> rather than on that list itself.
|
|
| Jun 4, 2016 at 15:32 | comment | added | Taemyr | @Kyralessa We are passing a List of CalendarRows. Not a list of Calendars. I agree that a class Calendar would be cleaner code, but that is not what OP is using. | |
| Jun 3, 2016 at 19:47 | comment | added | Kyralessa | @Taemyr, sure, but we're talking about a collection. Even if you were collecting the calendars and then passing them, you wouldn't pass a null to say "None of these people have calendars." If you passed anything, it'd be an empty collection. You also wouldn't pass a collection containing either a null or a calendar for each person. You'd just pass the calendars that exist. I've never seen a single good reason in .NET to pass a null instead of a collection, or to pass a collection that contains any nulls. | |
| Apr 23, 2016 at 16:06 | comment | added | Kevin | Unless and until the requirements change, it is redundant and useless noise. After all, currently it will never be empty - you can't predict future changes, so how could you possibly know why it would be empty? And if you don't know why it would be empty, how can you write code to handle it? | |
| Apr 7, 2016 at 13:08 | history | edited | gnat | CC BY-SA 3.0 |
personal details removed
|
| Apr 4, 2016 at 5:14 | comment | added | BlueWizard | It's bull when it's not initalized. Obly initalized objects have properties like .count() | |
| Apr 1, 2016 at 13:05 | history | tweeted | twitter.com/StackProgrammer/status/715887889578659840 | ||
| Apr 1, 2016 at 10:58 | answer | added | AnoE | timeline score: 1 | |
| Apr 1, 2016 at 0:47 | comment | added | radarbob | Much to learn you have, young Padawon. much, much easier to enhance the code with new behaviours, because I don't have to go back and ensure that all the relevant checks are in place. ... less one thing. | |
| Mar 31, 2016 at 21:35 | answer | added | clime | timeline score: -1 | |
| Mar 31, 2016 at 18:35 | vote | accept | KidCode | ||
| Mar 31, 2016 at 9:38 | comment | added | Alex | I don't like the word "redundant" in this context. I'd use (potentially) unnecessary. | |
| Mar 30, 2016 at 22:36 | comment | added | CodeGnome | There's a balance between YAGNI and defensive coding. The artistry is in finding that balance. | |
| Mar 30, 2016 at 7:27 | history | notice removed | yannis | ||
| Mar 30, 2016 at 7:15 | answer | added | JacquesB | timeline score: 1 | |
| Mar 29, 2016 at 22:16 | comment | added | JacquesB | @KidCode: You actually answer the question yourself, by observing that this kind of code tends to hide bugs. Hiding bugs does not make the code more robust! Hiding a bug in the present because of a hypothetical future feature is like driving the car into a river because there is plans to build a bridge. | |
| Mar 29, 2016 at 14:07 | answer | added | Vi0 | timeline score: -2 | |
| Mar 29, 2016 at 14:04 | comment | added | Taemyr | @Kyralessa Imagine you have several persons you are tracking, and any one can have a calendar, but only a few of them will have a calendar. In such a scenario it can make sense to only initialize the calendar when it's needed. | |
| Mar 29, 2016 at 13:59 | comment | added | Taemyr | I find the logic in your function to be dubious. After section 2; If rows was null or empty you now have rows with App already added before you proceed with the rest of the code. If rows was non empty you do not have App added, and you proceed with the same code. | |
| Mar 29, 2016 at 12:34 | history | notice added | maple_shaft♦ | Current event | |
| Mar 29, 2016 at 12:33 | history | protected | maple_shaft♦ | ||
| Mar 29, 2016 at 12:08 | comment | added | Luaan | @PierreArlaud Yup. It's more like a trick played on the management, though - it's very easy to do TDD with no benefit at all ("test count/coverage as a metric"), while producing more code that needs to be maintained. In the end, you still need great programmers that care, and you still need to keep making sure that your tests are correct and relevant. I'm not yet at the point where I'd consider 100% TDD worthwhile, though I keep watching its evangelists periodically; but I can certainly see the appeal if you're on a team where management doesn't communicate with developers (QA, SE, UX, ...). | |
| Mar 29, 2016 at 11:58 | comment | added | Pierre Arlaud | @Luaan agreed, which is why TDD exists: build tests first, then the feature. You ensure that the feature is there, but that tests aren't omitted because of "lack of time". | |
| Mar 29, 2016 at 11:54 | comment | added | Luaan | @PierreArlaud Yes, that's also a cost you have to account for - if you don't, that's just bad economy and your own fault. Plenty of products and companies died of either of these causes. But in the end, I'm pretty sure that most products are on the "horrible" side - if you go too far in ignoring good code, testing etc., you're going to have grumpy programmers, but it rarely puts you out of business, compared to the other "extreme". You have to ship. It's always a bet, you're just picking the stakes and hoping for the best. It's still a business, and you're still resource limited. | |
| Mar 29, 2016 at 9:21 | comment | added | Davidmh | Related talk in a PyCon: Stop writing classes | |
| Mar 29, 2016 at 9:14 | comment | added | Pierre Arlaud | @Luaan that's the usual horribly wrong excuse for doing no tests. Time not spent now could result in more time required in the future. | |
| Mar 29, 2016 at 9:07 | comment | added | Luaan | A quick note: you always have deadlines. Even when there's no customer-set deadline, you have to account for opportunity costs - whatever you do, you could have been doing something else in the meantime. If that something else has more value, you're losing value by not doing it. And if you never ship... :) | |
| Mar 29, 2016 at 8:36 | answer | added | Luaan | timeline score: 2 | |
| Mar 28, 2016 at 20:19 | comment | added | Criticizing Israel not allowed | That said, the code in question appears to be using null to represent an empty collection. | |
| Mar 28, 2016 at 20:19 | comment | added | Criticizing Israel not allowed | @Kyralessa The reasons for other variables to be null still apply to collections; it's "don't use null to represent an empty collection" not "never let collection references be null." | |
| Mar 28, 2016 at 17:41 | vote | accept | KidCode | ||
| Mar 31, 2016 at 18:35 | |||||
| Mar 28, 2016 at 16:30 | comment | added | Kyralessa |
Why would rows ever be null? There's never a good reason, at least in .NET, for a collection to be null. Empty, sure, but not null. I would throw an exception if rows is null, because it means there's a lapse in logic by the caller.
|
|
| Mar 28, 2016 at 16:09 | answer | added | Lightness Races in Orbit | timeline score: 11 | |
| Mar 28, 2016 at 15:54 | answer | added | JeffO | timeline score: 1 | |
| Mar 28, 2016 at 9:39 | answer | added | deworde | timeline score: 3 | |
| Mar 28, 2016 at 5:57 | comment | added | Robert Koritnik |
You do realise that EVERY TIME you hit first if, you'll also hit the second. Which means that you actually need the second one as well if your code depends on it.
|
|
| Mar 28, 2016 at 2:35 | history | edited | svick |
edited tags
|
|
| Mar 28, 2016 at 1:47 | answer | added | Eric Lippert | timeline score: 180 | |
| Mar 27, 2016 at 22:04 | comment | added | Martin Schröder | No. Please read about Clean Code. | |
| Mar 27, 2016 at 22:03 | answer | added | Kevin | timeline score: 24 | |
| Mar 27, 2016 at 20:50 | comment | added | Ben Cottrell | I'd say that there's quite a difference between 'defensive code' (which is what it looks like you're doing here) versus 'future code'. But in any case, you might find this blog post interesting on the subject of future/YAGNI code: sebastiansylvan.com/post/the-perils-of-future-coding | |
| Mar 27, 2016 at 20:15 | answer | added | Tyler Durden | timeline score: 9 | |
| Mar 27, 2016 at 19:52 | comment | added | Daniel T. | Sure, "... if section one is true, then section two will also be true." but what if section one is false? Then section two might be either true or false. | |
| Mar 27, 2016 at 19:29 | answer | added | gnasher729 | timeline score: 5 | |
| Mar 27, 2016 at 19:26 | comment | added | Theodore Norvell | Irrelevant to the question, but I suspect your code has a bug. When rows is null a new list is created and (I am guessing) thrown away. But when rows is not null, an existing list is changed. A better design might be to insist that the client pass in a list that may or may not be empty. | |
| Mar 27, 2016 at 19:21 | answer | added | Theodore Norvell | timeline score: 6 | |
| Mar 27, 2016 at 18:39 | answer | added | Adam Zuckerman | timeline score: 89 | |
| Mar 27, 2016 at 18:11 | review | Close votes | |||
| Apr 1, 2016 at 3:01 | |||||
| Mar 27, 2016 at 18:05 | answer | added | Ewan | timeline score: 7 | |
| Mar 27, 2016 at 18:04 | answer | added | cmaster - reinstate monica | timeline score: 35 | |
| Mar 27, 2016 at 18:01 | comment | added | knut |
If you know if(rows.Count == 0) will never happen, then you could raise an exception when it happens - and check then why your assumption became wrong.
|
|
| Mar 27, 2016 at 17:58 | comment | added | KidCode |
@gnat - It's very similar, but I'm kind of targeting checks only here, not asking whether I should add in / change actual functionality just in case it might be needed in the future.
|
|
| Mar 27, 2016 at 17:56 | comment | added | Roman Reiner | In software development things that should never happen happen all the time. | |
| Mar 27, 2016 at 17:55 | comment | added | gnat | Possible duplicate of Design for future changes or solve the problem at hand | |
| Mar 27, 2016 at 17:51 | history | asked | KidCode | CC BY-SA 3.0 |