Details
-
AboutProfessional programmer, hobby japanologist.
-
SkillsC#.NET, C++, Software architecture
Joined devRant on 2/7/2020
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
I'm going to confess: I am the type of developer that creates the ExcruciatinglyLongAndSpecificClassNameObject with the UtterlyDetailedExplanationMethod. It's just a thing I keep doing, despite voiced frustrations from people I've worked with. It just feels right in the mindset of self-documenting code
And while I acknowledge this isn't a flawless process, I see no other way around without losing information. I've tried alternatives, but everything feels like trading one issue for another:
- Abbreviations work as long as they are well known (XML, HTML, ...). As soon as you add your own (even if they make sense in the business context) you can bet your ass someone is going to have no idea what you're talking about. Even remembering your own shit is difficult after X months.
- Removing redundant naming seems fine until it isn't redundant anymore (like when a feature with similar traits gets added). and you can bet your ass no-one is going to refactor the existing part to specify how it differs from the newly added stuff.
- Moving details to namespaces is IMO just moving the problem and pretending it doesn't exist. Also have had folks that just auto-include namespaces in VS without looking if they need the class from namespaceA or namespaceB and then proceed to complain why it doesn't compile.
So, since I am out of ideas, I'd like to ask you folks: Is it possible to reduce class/method name lengths without losing information? Or is self-documenting code just an ideal I'm trying too hard to achieve? Or are long names not a problem at all? I'm looking forward to your answers.19 -
If you want to learn about bad UX design, look at every GDPR-compliant cookie alert on websites. The dialogues generally follow this pattern:
* Highlighting "Accept all" instead of "Reject" to bait you into habit-clicking.
* After clicking "Reject", you'll be redirected to an infinite list of usages. There is never a "deselect all" option. You need to opt-out everything manually.
* Sliders use some ambiguous coloring scheme without labels, which means you never know if you turned it on or off.
* Instead of "Reject", there is an "Other options" button. Clicking it redirects to a EULA document, with at the end... no other options.
Everything looks compliant, but they are still boobietrapping everything so you just wouldn't be able to opt out. Fucking data-vendoring assholes.17 -
Today I've been summoned to work for the first time in weeks to help with the startup of a machine, and testing the HMI software that goes with it.
Me and a junior colleague go to the machine. We try to get everything ready for testing. Machine was left stuck in some intermediate state by someone else. I have no idea on how to control the machine's individual components. My colleague received a crash course a while ago, but was unable to reinitialize the damn thing, and the senior machine builder was too busy on another project.
In other words, me coming over had no purpose at all, and we accomplished nothing.
I really don't understand companies. On one end there's an endless bitching about how everything is too expensive, and on the flip-side you see 'em toss buckets of money through the window.
Oh well, as long as it goes from the window to my bank account, there's no problem for me I guess.2 -
Dear DevRant,
The yellow background looks great on our avatar, but could you please not use it as background for a rant? You're burning the eyes out of my skull.17