Forums
It is eminitently reasonable for companies to have "readability standards" for their code. You're writing this code for humans to read, after all, at least in theory. You need to communicate to future inheritors of your code.
But that doesn't mean readability standards are good. Tony's company, for example, has rules about returning boolean values from functions, and those rules mean you are expected to write code like this:
Today's anonymous submitter passes us a single line of JavaScript, and it's a doozy. This line works, but that's through no fault of the developer behind it.
{arr?.length && shouldNotShow === false > 0 (...)}
Capybara James sends us some code which is totally designed to be modular.
This particular software accepts many kinds of requests which it then converts into a request for a ListView. This is a perfect example of where to use polymorphism, so you can write one transform method that operates on any kind of request.
Dana sends us a WTF that'll turn your head. She was shopping for new hard drives, and was doing it from her phone, a fairly reasonable tool to use for online shopping these days. She opened the website of one vendor, and it was rotated 90 degrees. Or half-pi radians, for those of us that are more used to sensible units.
This was irrespective of any rotation settings on her phone, the website insisted on showing itself in landscape mode. This created quite the unusual appearance when she held her phone in portrait orientation: the browser chrome surrounding the content was in portrait mode, but the page itself was in landscape.
Today's Anonymous submitter sends us some React code. We'll look at the code and then talk about the WTF:
// inside a function for updating checkboxes on a page
if (!e.target.checked) {
const removeIndex = await checkedlist.findIndex(
(sel) => sel.Id == selected.Id,
)
const removeRowIndex = await RowValue.findIndex(
(sel) => sel == Index,
)
// checkedlist and RowValue are both useState instances.... they should never be modified directly
await checkedlist.splice(removeIndex, 1)
await RowValue.splice(removeRowIndex, 1)
// so instead of doing above logic in the set state, they dont
setCheckedlist(checkedlist)
setRow(RowValue)
} else {
if (checkedlist.findIndex((sel) => sel.Id == selected.Id) == -1) {
await checkedlist.push(selected)
}
// same, instead of just doing a set state call, we do awaits and self updates
await RowValue.push(Index)
setCheckedlist(checkedlist)
setRow(RowValue)
}
Aankhen has a peer who loves writing Python scripts to automate repetitive tasks. We'll call this person Ernest.
Ernest was pretty proud of some helpers he wrote to help him manage his Docker containers. For example, when he wanted to stop and remove all his running Docker containers, he wrote this script:
Every once in awhile, we get a bit of terrible code, and our submitter also shares, "this isn't called anywhere," which is good, but also bad. Ernesto sends us a function which is called in only one place:
///
/// Shutdown server
///
private void shutdownServer()
{
shutdownServer();
}
We mostly don't pick on bad SQL queries here, because mostly the query optimizer is going to fix whatever is wrong, and the sad reality is that databases are hard to change once they're running; especially legacy databases. But sometimes the code is just so hamster-bowling-backwards that it's worth looking into.
Jim J has been working on a codebase for about 18 months. It's a big, sprawling, messy project, and it has code like this: