I forgot the alt text 🤦 here's the markdown (source):
Trimming whitespaces before line splicing
As of C++20, what's the output of the below piece of code (Godbolt)?
int main() {
int i = 1
//
+ 42
;
return i;
}
Without having seen how the code is formatted I would have said that it's 1 + 42, so 43. And actually, that's the real output. On MSVC. Not on other compilers, such as GCC and Clang.
These latter ones return 1. The reason is that they trim the trailing whitespaces before handling splicing. The new-line character following is a whitespace, it's deleted, therefore + 42 ends up on the same line as // and it becomes part of the comment.
Just for the record, both implementation strategies are valid.
P2223R2 change this situation and set the GCC/Clang implementation strategy into stone standard. This might be a breaking one for code that is only compiled with MSVC, but it shouldn't happen on a big scale.
The reason behind going in this direction is that many IDEs, code formatters and other tools already discard trailing whitespaces as the Google style guide and most of its derivations already forbid them.
I've changed the Godbolt link and code because the original didn't have the trailing whitespace, lol.
I think that there’s one important point to consider that may not be immediately obvious, when deciding about commit messages in FOSS project, even if you are not accepting contributions and just want to share your work for others - auditabilty.
7-zip has been receiving critique for this for a long time - not having commit messages makes it way harder to check what the actual changes were. Sure you can’t trust commit messages during an audit, but it makes it a lot easier - either you immediately notice that they are lying, or they are correct and will help you with understanding the change, so you can decide for yourself whether it’s safe.
Of course, the author is doing a lot of work for free, that he offers to others, so we have no right to blame him for it or demand he changes his approach. I’m grateful for any FOSS project, and demanding from someone directly that he’s doing it wrong and should do it some other way (or belittling him for it) isn’t OK. However, I’d probably be very careful when encountering a repository like this, and reconsider whether it’s worth adopting. Which is absolutely ok and I don’t blame the author for it in the slightest - it’s his repo and his work - but I also think that auditability may be something the author didn’t realize, and assuming his goal was to share his code with others i.e to build a portfolio, may affect his overall adoption rate. But it’s also ok if he simply doesn’t care about that.
But in general, if you’re making a FOSS project, I’d recommend sticking with good commit messages.
Commit messages are as much for me as other people tbh. As long as your commits aren’t massive I don’t really think it’s much work either for the benefits.
But like you say we have no right to demand anything from people giving up their free time for us. We can just choose not to use it.
This. Like if they are working for free for the public good, don’t complain if they don’t do it thoroughly enough. If someone volunteers to pick up trash from the park, you wouldn’t complain if he misses some things or stops before the whole park is clean.
For me, the thing is, commit messages aren’t just for other people. They can be invaluable in case you need to look back for something. I even write them for my personal repos that aren’t even on the internet, because it’s really just kinda dumb not to.
Yeah, but that doesn’t mean that everyone else has to work as methodical as you do for any project they do. Even if it is more efficient and saves time in the long term.
Okay, so how is it possible to make quality open source software, if you don’t expect the programmer to do a good job, and instead you praise them for doing whatever?
Yeah, exactly. Which is a completely different beast when the open source project is made by 3 dudes in a basement. So either you get support from a huge foundation like Apache, spend your own money for little gain, or your project is shitty quality-wise
The only way you can start expecting quality is if you start paying for it. Otherwise you are just judging people for how badly they built their hobby project in their free time.
It might currently be complicated to do that but that just means we need infrastructure. Start complaining about that or do something about it if you want more quality open source software.
It’s not even the “quality of the project” like suggested in this thread. It’s the quality of the commit messages (meta-data, documentation)
That’s like someone who paints for a hobby, and shows their paints off on the internet, and people would post stuff like “Well cool painting, but you didn’t really explain what kind of paint you’ve used, who your inspirations were” etc etc
When I’m building Open Source stuff as a hobby for things that are useful to me, and also dump them on Github - because it’s a good backup system - I don’t really care whether people might go through the commit history as means to figure out how I’ve build it
I’d say that good documentation is also a part of quality of a software project, more so than in other fields, but I do agree that it is one of the things you can just forget about for personal projects.
market capitalism will prioritize putting most resources into spyware and adware that turns the consumer into a product. Along with that constant reinventing of the wheel in proprietary software in the name of “competition”, even though index/hedging funds oligopoly leads us into stagnation in terms of innovation these days with one ‘next great thing’ after another turning out to be mostly an overspeculated fad. I’d say vote for pirate parties but that’s actually BS as is all parliamentary politics in this quasi-aristocratic system, even if they launch large scale grant programmes they’ll very likely back down on them whenever an economic slump happens.
Just don’t use it if you don’t like it. And you may not believe it, but there are also OS devs out there that - as a hobby - leave the park behind sparkling clean. It’s not like everyone would produce low-quality open source projects, but no one is entitled to judge a low-quality project.
Well, the first step is to not be an elitist gatekeeper who scares away any beginner who tries to develop open source stuff. Because even if their first few repositories were not exactly good, they may eventually get better, and if their experience with FOSS community was a pleasant one, there is a pretty high chance they will publish their later work too.
If, on the other hand, you publicly shame every mistake a beginner makes in hist first repository, they will probably never publish anything.
It’s important to praise anyone who’s self-less enough to write FOSS. Even if they aren’t exactly good yet, just the fact that they have decided to publish it is really important. I’m not saying that we shouldn’t offer any negative feedback - quite the contrary - but the feedback definitely shouldn’t be public shaming in a meme post on random social network.
Yeah for sure don’t shame them. But also, don’t merge code that is bad. Opensource needs standards too because at the end of the day it’s competing with closed source. Even if it’s a first contribution, you probably shouldn’t merge things without tests, without commit messages, etc
Eh, I still think it’s worth calling out sloppy practices like this. At a minimum, drawing attention to it is a way to socialize good practices for others and to spark discussions (like this one!) Nobody is saying this person shouldn’t be putting code out there, they’re just pointing out some pretty gnarly code hygiene. One could argue this is actually one of the main strengths of open source development! Consider the parallel of somebody giving away free food- if they are using unsafe practices like not keeping things at proper temperatures or picking their nose while handling food, there’s nothing wrong with critiquing them, even if their intentions are good.
I agree, however I think that we could’ve raised the issue even without directly mentioning the developer or his repository, and could have discussed it without directly pointing at someone who did it.
Because that only derailed the discussion into whether he personally can or cannot do it (which he definitely can), instead of focusing on the best practices about commit messages in FOSS projects in general.
I also think that there’s a pretty huge difference between offering someone advice directly when interacting with him, such as your example about unsafe food practices, and posting a meme post with his name to an entirely unrelated social network.
So, for your example, I think it’s ok to either talk to the guy handing out food, to comment on his post about it. However, if you took a recording of him doing it, and posted it publicly to Facebook while mentioning him by name (and not even tagging him, so he isn’t notified) - that’s not a good way how to give meaningful feedback or critique.
It’s certainly not as if anyone is entitled to anything better. It’s just bad practice. I wouldn’t want people critiquing me based on the work I do for free either, though.
And that’s the issue I have with that. Imagine you are fabricio and you find this post. Next time you probably won’t make it public even if there is a remote chance, that it might help someone else.
I agree, the post shouldn’t have called him out directly by name. It should’ve been a post of just a screenshot with the commit messages, and not mention the repository or the person. It’s definitely not nice, and may even affect the person - I mean, if I was called out like that somewhere and seen people laughing at my practices, I wouldn’t be exactly happy.
On the other hand, I think that raising the issue in itself - FOSS repositories without commit messages - is a pretty good discussion that fits here well. It’s just a shame that it had to be at the expense of some FOSS developer, because it also derails the discussion into talking more about the guy and whether he can or cannot do it (such as your comments, which I agree with), instead of focusing on what are the issues with FOSS projects without commit messages in general. Because there are many arguments why it’s important, and a few arguments about why it shouldn’t matter, which makes for an interresting discussion about best practices and why they are important.
calling map(obj.func) will pass func but won’t set the this parameter correctly. If the called method uses this you will have a bad time.
The code you actually want would be retval.map(v => self.cleanupMetadata(v)) or the old-skool retval.map(self.cleanupMetadata.bind(self)).
Also the first version reuses the Array which may be important, but even if not will likely result in better performance. (Although this is likely mitigated by making the array polymorphic depending on the return type of cleanupMetadata and the overhead of forEach vs map.)
i mean shit, it’s a legacy code issue. they made that format in the ninties to work with the limitations of 90s computers. since then they’ve just kept adding features and not starting over. it’s the same reason the davinci resolve has better color tools and is way less crash prone than premiere. premiere can’t do direct color manipulation, it does some kinda weird simplified math based on some kind of analogous curve or something like that. 90s computers simply couldn’t handle the amount of color calculations needed to do it properly. resolve just uses your modern system to do the direct calculations. idk, i barely understand it and I’ve only ever met like 2 people that could tell me more about it…
When they say writing code comments is important this is what they mean. This is how we programmers pass on important life lessons that save the next dev weeks of heart pain and hair loss.
programming_horror
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.