• Tim (unregistered)

    At this point just vibe code ts - can't even get worse...

  • AzureDiamond (unregistered)

    another reason kotlin is better than java. optional parameters are just fun foo(arg0: String, arg1: Int = 0) not 3 lines of boilerplate for every optional so theres no reason to avoid them

  • (nodebb)

    Wait, they're worried about having to modify the parameter list because of database changes, but not about having to modify the code processing the parameters? You moron, you have to modify code anyway, why not have compile-time checked parameters? :FACEPALM:

  • Hans (unregistered)

    "No, all of our arguments are required. We'll just default the ones that the caller doesn't supply."

    I can't quite get my head around this: required arguments, but the user doesn't need to supply them? And then just take a default value?

  • (nodebb)

    It's universal code, no matter what the universe wants, this code can handle it! Right up until it crashes the universe.

  • (nodebb) in reply to AzureDiamond

    This is C#, not Java. And it also has optional parameters.

  • (nodebb)

    I've personally witnessed this happen like eleventy-billion times. The worst was a contractor that created a general-purpose method to be used by any code that calls a stored procedure. The method inspected the proc and dynamically created local parameters for any parameter define on the procedure, then did something very similar to today's WTF.

    It was just as bad as today's submission, with one bonus. We couldn't ever add any parameters to a stored procedure without simultaneously rolling out code updates. Sure, SQL Server supports default parameter values for parameters not supplied by the client, but the genius that wrote this code inspected the proc at run time, so all parameters were always supplied, even those added to the procedure later.

    Another variant of this is "Let's put the code in a stored procedure so we can change it without the hassle of change-control approval!!". Wait, what?

  • (nodebb)

    "Let's put the code in a stored procedure so we can change it without the hassle of change-control approval!!"

    Hmmmm....

    I do that a fair bit on the two web applications I'm maintaining, but not to avoid the code-review process --- that still happens. I do it to simply run an ALTER PROCEDURE script and avoid deploying the application. Am I guilty of non-optimal practices?

  • (nodebb)

    Makes me flash back to the glory days of C (especially real mode!) where you passed a pointer to a blob of memory and assumed the receiver knew what it meant.

  • TrueWill (unregistered)

    Let's put the code in a stored procedure so we can change it without the hassle of change-control approval!

    A "better" variant I've seen: Let's put the SQL in a database record, as the DBAs make changing stored procedures too hard.

  • Chris (unregistered)

    "No, all of our arguments are required. We'll just default the ones that the caller doesn't supply."

    Isn't that what optional arguments are used for in C#????

  • Officer Johnny Holzkopf (unregistered)

    Another WTF included is the assumption of "our page and user IDs consist of digits, so it must be integer numbers", same as ZIP codes or phone numbers or article identifiers; "int pageId = (int)al[0]; int userId = (int)al[1];" is a perfect example of the "digits equal int" mentality...

  • Nick (unregistered) in reply to dpm

    I do it to simply run an ALTER PROCEDURE script and avoid deploying the application. Am I guilty of non-optimal practices?

    Unfortunately, yes, you are guilty of non-optimal practices. Sure, you can just update the one stored procedure… but what happens when you have multiple stored procedures, and they start to have interdependent logic? Ideally, you should deploy the entire application - including both “code stored in the database” and “code stored in the file system” at the same time, to avoid any situation where the two become out of sync - or worse, your fix to a stored procedure relies on a change to your other code, which is not yet deployed.

    That said… a sufficiently advanced deployment mechanism could (perhaps should?) detect if the application code hasn’t changed since the last deployment, and therefore skip the deployment of that code and just run the database updates… and could (perhaps should?) also avoid restarting the application server in that situation.

    If your projects are simple enough that you can maintain the entire context in your head, and you have 100% confidence in your knowledge of what is deployed where, you yourself could become that advanced deployment mechanism… so arguably, what you’re doing isn’t bad practice at all, it’s ahead of the curve!

    PS - how do I quote properly here?

  • LZ79LRU (unregistered) in reply to n9ds

    God I miss those times.

  • (nodebb) in reply to dpm

    I do it to simply run an ALTER PROCEDURE script and avoid deploying the application.

    No, you're guilty of having poor deployment practices for your website, but good ones for your database. When I deploy a website, I go into Jenkins and push the "Approve" button on the Prod promotion. This button, which has been pushed hundreds of times, determines which of the two production nodes is currently handling traffic, deploys to the other node, verifies the new node responds to a few simple requests, then reconfigures the load balancer to route new requests to the node it just deployed to.

    If I were to deploy an updated stored procedure, I would go to Jenkins and push the "Approve" button on the Prod promotion of the database source code project. This button, which has been pushed hundreds of times, would run any script that has been checked into the project from the one after the last run script, until the most recent script. In this case, it would run the ALTER PROCEDURE statement that you would have run manually.

    It's 2025, why are you still doing deployments by hand?

  • (nodebb) in reply to Nick

    @Nick ref

    PS - how do I quote properly here?

    This site uses is Markdown, or a small subset thereof. Prefacing a paragraph with > makes it an indented shaded box. If you're quoting multiple paragraphs without intervening blank lines, one > at the start will suffice. If your multiple paragraphs have intervening blank lines then you need to include a > at the start of each paragraph and on any intervening blank lines. So this example uses three >s.

    Para 1 blah blah Para 1 blah blah Para 1 blah blah Para 1 blah blah Para 1 blah blah Para 1 blah blah Para 1 blah blah

    Para 2 foo bar Para 2 foo bar Para 2 foo bar Para 2 foo bar Para 2 foo bar Para 2 foo bar Para 2 foo bar

  • (nodebb)

    PS - how do I quote properly here? @Nick Thank you, TIL.

    Addendum 2025-08-15 15:35: Of course it helps to do it right.

Leave a comment on “An Array of Parameters”

Log In or post as a guest

Replying to comment #683251:

Log Out

« Return to Article