User not logged in - login - register
Home Calendar Books School Tool Photo Gallery Message Boards Users Statistics Advertise Site Info
go to bottom | |
 Message Boards » » Stupid Software Engineering & Design Decisions Page 1 2 3 4 5 [6], Prev  
FroshKiller
All American
50761 Posts
user info
edit post

We have a class for building HTML forms so you don't have to write HTML. It's largely undocumented, which is annoying. I was interested in using it, though, and noticed two public subroutines that seemed to be related to adding instances of our control types to the form. Here are their signatures:

Public Sub AddControl(Label As OurCustomLabelClass, Control As OurBaseControlClass)
Public Sub AddInteriorControl(Control As OurBaseControlClass)


I was interested in adding some checkboxes to the form. Our custom checkbox class renders its own label element. So I did what I thought was the natural, sane thing and opted for the subroutine that didn't have a required parameter of the label type.

The form did not render with any of my checkboxes. When I stepped through the code, I saw that they definitely got instantiated, and the calls to the subroutine definitely ran without exceptions.

I spent about 30 minutes troubleshooting this fucking thing until I finally searched the code base for another instance of someone adding a checkbox to a form through this builder. Care to guess what they did?

They called AddControl and passed Nothing for the Label parameter.

[Edited on April 24, 2017 at 12:53 PM. Reason : Peace, we outta here.]

4/24/2017 12:53:45 PM

aaronburro
Sup, B
51515 Posts
user info
edit post

Yeah, in a case like that, I would opt for AddControl first, based solely on the strange name of AddInteriorControl. Undocumented code is the best.

4/27/2017 12:34:22 AM

FroshKiller
All American
50761 Posts
user info
edit post

I understand why this is, but I'm annoyed as shit that getting the weekday from VB's DatePart function returns a value that doesn't naturally line up with .NET's DayOfWeek enum.

5/9/2017 7:56:43 AM

CaelNCSU
All American
6079 Posts
user info
edit post

Feature: Really important switch in the UI for turning on and off live programming.

1) Create web app for button to toggle live events on/off
2) Web app makes post request to 2nd web app
3) Web app #2 puts message on a Queue
4) Consumer of queue picks up the message and updates the database.
5) Web app #3 displays results in the UI to the end user.

No tests around any of the individual pieces or the system as a whole, so it breaks, constantly and no one knows why.

5/11/2017 7:32:46 PM

JeffreyBSG
All American
10117 Posts
user info
edit post

OLD remote environment was a nice pseudo-desktop in which you could edit your code in GEDIT and save it with CTRL-S

NEW remote environment is a cocksucking folder-navigation system with this dickless web-browser text window, in which you have to click the SAVE button to save anything

really fucking annoying to have to click a button with your mouse every time you want to save

5/11/2017 10:29:47 PM

FroshKiller
All American
50761 Posts
user info
edit post

Someone who should've known better checked some garbage code for generating a spreadsheet that he found on some damn message board into the common application framework, and other people have already started using it, so now we're chained to the goddamn thing.

5/26/2017 1:42:10 PM

FroshKiller
All American
50761 Posts
user info
edit post

A concise illustration of everything wrong with this codebase:

If bSendPhotos = -1 Or bSendPhotos = 1 Or bSendPhotos = 2 Then

6/14/2017 7:53:16 AM

smoothcrim
Universal Magnetic!
18136 Posts
user info
edit post

^^ you sure the stupid decision isn't the code review process?

6/14/2017 9:19:20 AM

FroshKiller
All American
50761 Posts
user info
edit post

That would be the larger problem, yes.

6/14/2017 9:44:09 AM

FroshKiller
All American
50761 Posts
user info
edit post

The spreadsheet code I mentioned before is a "class" that consists solely of shared methods, not a single field nor property nor even private data to be seen.

7/14/2017 7:32:56 AM

FroshKiller
All American
50761 Posts
user info
edit post

I just clicked on a region named "Public Property," and the only thing I saw on screen when it expanded was about 20 lines of private fields.

8/9/2017 8:37:12 AM

aaronburro
Sup, B
51515 Posts
user info
edit post

I hate when people hide fields in regions like that. Group sections of related code, if you must, but fuck off with regions just to say where private fields are.

Anyway, the product I work on has a validation system that we built that is, to say the least, buggy. It's solid most of the time, but it does have some very nasty potential for race conditions. The end result is a way to validate some small piece of the VM, and provide an validation status (pass/fail/warning) and error message. The application ends up displaying all of the errors and warnings in a status bar. The validation pieces are VMs themselves. It's rough, but it's hobbling along nicely.

Well, our genius offshore guy, who I wouldn't hire as a junior dev, gets assigned a task to require user acknowledgement of something before you can submit from the CRUD screen. We already have a pattern for this in our validation structure, and it does a standard pop-up. Or, you could have a button that shows up dynamically on the CRUD screen when applicable. Whatever. Pretty standard stuff, right?

Well, this guy decides "fuck all that. I'm gonna go add a button to the validation VMs, which are asynchronously created and recreated as needed. And I'm gonna make sure this button shows up on EVERY validation result, not just the one I've created." So, now, our error messages and warnings ALL have a button on them which does nothing, except for his new one.

When I called him on it, his response was "I tested it, and it works fine."
I reverted it.

BTW, this is the same guy who needed to add a button to our settings screen, which is dynamically generated. It loads a list of settings and reads them into a generic "ConfigSetting" type, where the generic parameter is some kind of serializable construct, and the whole things is autoserialized into a database somewhere. These ConfigSettings get read at app startup, and when you load the settings screen, it just creates a list of settings that can be edited. OK, so the system isn't set up very well to allow just throwing a button on there to perform a certain action... So what does this guy do? Rework the screen to allow a custom view to be added? Of course not. He creates a ConfigSetting{Button} that gets auto generated, providing you the button, which you then can click.

It kinda works, except for a small problem. A button isn't really deserializable. So, as long as you never save your settings, you are fine. But the moment you save, that button gets "persisted" into the database, and then the app won't load anymore, because HOW THE FUCK DO YOU DESERIALIZE A FUCKING BUTTON. And the only fix is to delete ALL of your settings from the database, because we store all settings in a single, binary object, that can't easily be pulled out.

[Edited on September 2, 2017 at 4:45 PM. Reason : ]

9/2/2017 4:33:27 PM

FroshKiller
All American
50761 Posts
user info
edit post

That dude sucks, but can't you strip the buttons from the settings before saving?

I just broke a release build, because the release build system uses an older version of the compiler than, like, every other programmer and every build configuration in the QA environment.

9/19/2017 8:42:01 AM

aaronburro
Sup, B
51515 Posts
user info
edit post

Well, sure, but we shouldn't have to write code to strip out buttons from settings... Ultimately, I spent about half a day doing what the original dev who wrote our settings code should have done: give us a way to specify a different UI for certain settings categories.

9/24/2017 3:05:19 PM

 Message Boards » Tech Talk » Stupid Software Engineering & Design Decisions Page 1 2 3 4 5 [6], Prev  
go to top | |
Admin Options : move topic | lock topic

© 2017 by The Wolf Web - All Rights Reserved.
The material located at this site is not endorsed, sponsored or provided by or on behalf of North Carolina State University.
Powered by CrazyWeb v2.37 - our disclaimer.