- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Edit Admin
She loves it when I get access to section G.
Ok I'll see myself out
Edit Admin
Yeah, if that fall-through pattern is a correct implementation of a business rule, it should fscking well be commented as such.
But what really grinds my gears is that that long test is repeated ad nauseam instead of being centralized.
Admin
Notice the beautiful inconsistency: to provide access to SectionA there must be an entry other than NoAccess, while for all the others missing value gives the access to the corresponding section.
Edit Admin
And also the mysterious use of
else return UiItem.Unknown;when that is not in the enum definition forUiItemwhich should be an error.Admin
TRWTF, however, is that the random-generator used on this site to go to a "random" article, has the same quality as the submissions posted here.
Edit Admin
Yeah, someone failed hard at De Morgan's Law on this one.
Edit Admin
So if currentAccess is empty we always get UiItem.sectionB?
Edit Admin
10 years in chroot jail for this violation.
Edit Admin
Wow! Messy.
It seems section A is special and sections B-G is not as special.
For section A/highest level, you need to have access (an entry in the currentAccess-map/table/array, whatever it is) and it cannot be NoAccess.
For sections B to G you have automatic access unless you have been denied access (NoAccess again).
Which of course will cause all kinds of funky security incidents, but maybe it makes sense for this app. E.g. section A is admin access, B-G is different parts of the public site?
Anyway, messy!