January 12, 2022 at 12:00 am
Comments posted to this topic are about the item Coding for the Future
January 12, 2022 at 6:59 am
Hardcoding as a sin is all well and good, but what do you do in the case of a date-from-date-to pair of columns? When all entries but the last date-to entry per series are NOT NULL?
Is it preferable to declare the date-to column as NULL (and allow for entries that shouldn't be NULL be NULL?). In these cases, we use a date far off in the future (say 2099) and keep the column NOT NULL.
While it is not ideal (nor is it, strictly speaking, true), it does allow for more performant SQL. There is no need to check for nulls and no need for functions in the WHERE-clause.
January 12, 2022 at 12:14 pm
Hardcoding as a sin is all well and good, but what do you do in the case of a date-from-date-to pair of columns? When all entries but the last date-to entry per series are NOT NULL?
Is it preferable to declare the date-to column as NULL (and allow for entries that shouldn't be NULL be NULL?). In these cases, we use a date far off in the future (say 2099) and keep the column NOT NULL.
While it is not ideal (nor is it, strictly speaking, true), it does allow for more performant SQL. There is no need to check for nulls and no need for functions in the WHERE-clause.
I hate "magic" values in general, but agree that examples like this help to keep the code cleaner, more readable and more performant. What is worse is inconsistency; our data warehouse imports from another system via JSON files and sometimes the end date is NULL and others it's 4712-12-31 (the source system is Oracle and that's apparently the maximum value for the underlying datatype). The earliest start date is variously NULL, 1900-01-01 and -4712-01-02.
January 12, 2022 at 2:08 pm
I don't know what logic was executed inside the loop. If it was querying the database for each iteration (bad design pattern to start with), then I can somewhat understand the need to for some upper limit. For similar situations, I first use something like MAX(year) to get the upper limit, so it's dynamic.
for ($i = $ThisYear; $i <= $MaxYear; $i++) { "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 12, 2022 at 2:18 pm
You're blaming the developer -- are you so sure it was their fault?
"No, don't worry about that, just get it done, we'll fix it later." (ever head "management" say that?)
There are certainly enough less-experienced developers who would not see the problem and I agree a "good" developer probably would have noticed the issue (though not necessarily been empowered to fix it), but it's not just the developer's failure here..."management", the testing team, other developers...nobody noticed? That's as much a failure of the team as it was the developer of the code.
January 12, 2022 at 3:03 pm
That could be, but when management dictates to developers how to code a for() loop, then it's time to polish up the resume and move on.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 12, 2022 at 3:38 pm
Taking off my DBA hat and putting on my developer hat. I agree with Steve that we need to think through scenarios for the code we write. Can we always think of all the edge cases? Of course not but some should be fairly evident. Even under pressure to get things done, code like the example here is something that should be fairly evident. As a developer, it's good to train yourself to look for edge cases as you're coding. And you learn that over time by seeing what bugs came up in your code. What broke. If you unit test your code before shipping it to QA you need to think of scenarios to test, You won't catch every one, but hopefully you make QAs job easier.
January 12, 2022 at 4:15 pm
Taking off my DBA hat and putting on my developer hat. I agree with Steve that we need to think through scenarios for the code we write. Can we always think of all the edge cases? Of course not but some should be fairly evident. Even under pressure to get things done, code like the example here is something that should be fairly evident. As a developer, it's good to train yourself to look for edge cases as you're coding. And you learn that over time by seeing what bugs came up in your code. What broke. If you unit test your code before shipping it to QA you need to think of scenarios to test, You won't catch every one, but hopefully you make QAs job easier.
I agree with you, Tom. However, I've made the same mistake. At my previous job during the change from one fiscal year to the next, when we went into the new fiscal year, we had to hold the funds for the old fiscal year, until all contractors had finished entering their data for the previous fiscal year and been paid. That normally was done within 30 days, but it was never the same day. However, I don't like the way I handled it. I hardcoded the ending date and fiscal year. Then changed the values in the relevant tables manually. It always felt dirty to me, but it was the only solution I could think of. Mea copa.
Kindest Regards, Rod Connect with me on LinkedIn.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply