Skip to main content
23 events
when toggle format what by license comment
Mar 1, 2022 at 9:38 answer added Phill W. timeline score: 3
Mar 1, 2022 at 9:31 answer added gnasher729 timeline score: 1
Mar 1, 2022 at 9:07 history edited Nae CC BY-SA 4.0
added 6 characters in body
May 13, 2020 at 6:00 history tweeted twitter.com/StackSoftEng/status/1260449697975713793
May 5, 2020 at 20:52 history became hot network question
May 5, 2020 at 17:48 answer added gnasher729 timeline score: 0
May 5, 2020 at 15:55 comment added candied_orange Reminds me of languages that let you have extra commas. Sure it’s a wart. But so are “get” prefixes. Avoid it if you can. Use it when you can’t. Never jumble.
May 5, 2020 at 15:46 comment added Eric King Adding noop code like that for the sake of code alignment seems like a big code smell to me. I'd hate to see that in any code base I'm supporting.
May 5, 2020 at 15:12 answer added Robin Bennett timeline score: 3
May 5, 2020 at 14:53 comment added Steve I agree with sentiments that this is more idiomatic in SQL than it is in procedural code, perhaps because SQL is more likely to be used interactively or to be subject to ongoing minor tweaking (so the ability to easily paste or comment out lines can be useful). If the code is to be maintained by others, it probably deserves a brief comment "for visual alignment of code only".
May 5, 2020 at 14:31 comment added Erik Eidt We can also add 0 and multiply by 1.
May 5, 2020 at 12:31 comment added πάντα ῥεῖ For SQL alignment and debugging purposes it's also common to write WHERE 1 = 1 ..., WHERE 1 = 0 ... respectively.
May 5, 2020 at 12:18 comment added amon I use this false or idiom a lot, precisely to keep the code more aligned. But it's super confusing for people who don't know it. In the SQL case, the more common approach would be to right-align the keywords.
May 5, 2020 at 12:03 comment added Doc Brown I would not recommend it. It always provokes a WTF by the next maintenance programmer.
May 5, 2020 at 11:45 answer added Martin Maat timeline score: 8
May 5, 2020 at 11:32 comment added Nae @BenCottrell It's just easier to (comment in / out) / add / remove the conditions thanks to them being kind of unattached to the other lines. Very much like ending a list with a ,. It disattaches the positional requirement from it.
May 5, 2020 at 11:21 review Close votes
May 13, 2020 at 3:02
May 5, 2020 at 11:21 comment added Ben Cottrell In fact, I'd say if your only reason for doing that is to communicate to other developers, then a far more direct and less cryptic way of doing that would be to add a comment which lays out your intention explicitly - for example /* Add new conditions here */
May 5, 2020 at 11:17 comment added Ben Cottrell Any code whose intention requires explanation about why you're doing it to someone reading or reviewing it the code seems undesirable to me. You've mentioned that your intention is to make the code more generic and easier to use, but even with that explanation I have to say I still don't understand what the point is, and honestly can't see how it makes the code more generic or easier to use. Maybe I'm just not smart enough to understand, but then it's often a good idea to assume your audience isn't very smart and keep in mind the Principle of least astonishment.
May 5, 2020 at 11:04 comment added Caleth Aside: I would change the second example to if (set(...).contains(prop))
May 5, 2020 at 11:00 history edited Nae CC BY-SA 4.0
added 1 character in body
May 5, 2020 at 10:55 review First posts
May 19, 2020 at 10:56
May 5, 2020 at 10:52 history asked Nae CC BY-SA 4.0