The liquor store presumably? Just submitting patches is a simple 12 step process. I can't imagine the development and review process is any easier.
I have implemented a Git client from scratch which involved quite a bit of reading the Git source code. It's not bad code but it's definitely the sort of code that would break in all sorts of unexpected ways if you changed something. I wouldn't volunteer my time their tbh.
You could do some of it in Python, but some stuff needs low level access to registers, e.g. trap handlers and context switching.
Should you do that? Absolutely fucking not. It would be hilariously slow and inefficient. Hundreds of times, maybe thousands of times slower than C/C++ kernels.
Git has four build systems?? Meson seems overkill if you already have CMake too. The only thing it really adds is that it's nicer to write (CMake is somewhere between Bash and PHP in sanity), but if you have to write CMake anyway...
They definitely didn't. Yes it is technically better to use their own new fancy system, but they're a business. Backwards compatibility is killer, even if you don't want it from a technical point of view.
I guarantee they looked at the numbers, interviewed users and asked them why they weren't using Deno, and the number one reason would have been "we'd love to but we need to be able to use the X node package".
They probably have to improve Node compatibility, but the Node API surface is actually not that big. They'll get there.
Yes, and then pass the context from the call sites of that function, and all the way up to main(). Oh look you're refactored the entire app.
That's best cases too, you'd better hope your program isn't actually a shared library running in a SystemVerilog simulator with state instantiated from separate modules via DPI, or whatever.
30 years my ass
lol when you have 30 years experience you will have actually tried to do this a few times and realised it isn't usually as trivial as you hope it would be.
ChatGPT or Claude. Just be aware that sometimes they'll get things convincingly wrong. If you're new to programming and asking simple questions then it should be relatively uncommon though.
I take time to explain why they aren’t duplicates of similar questions.
Ha yes I've found that if you explain why your question isn't a duplicate of another question and link to it, people are more likely to report it as a duplicate of that question. So stupid.
Only the visibility is local. The data is still global state. You can call that function from anywhere and it will use the same state. That's what global state means.
Some of the biggest issues with global state are that is makes testing difficult and it makes concurrent code more error-prone. Both of those are still true for locally scoped static variables.
Yes I know how static storage durations work. It's still global state, which is a code smell. Actually I'd go as far as to say global state is just bad practice, not just a smell. Occasionally it's the only option, and it's definitely the lazy option which I won't claim to never take!
I disagree. I've seen very complex boolean expressions and they were clearly code smell. Sometimes acceptable but definitely a fertile area for refactoring.
Their example is crap to be fair - two comparisons is not complex.
There are arguments to be made either way, but normally you’d scope your variables in a way that the ones specific to a particular bit of code are not accessible from elsewhere.
Sounds like you agree with that one to me? I'm not sure I follow their arguments about regions there (I've never used regions), but the example of declaring a variable in a block way before it is every used is spot on. I've seen code written like that and 99% of the time it's a bad idea. I think a lot of it comes from people who learnt C where you have to do that (or maybe Javascript which has weird rules for var).
Suggest writing a custom class to do what most languages can solve with inheritance or even better: the ? syntax.
Yeah I'll give you that one. They even suggest using Optional as a solution, which is what their "smelly" code did in the first place!
Yes, it can be annoying. No, clarity is more important than insisting on removing that extra underscore.
Not sure what your point is here. Of course inconsistent naming is a code smell. Do you want inconsistent names?
They’re advocating the use of a function to replace an expression. Sometimes this works, but the task of a boolean expression is not always easily expressed in a couple words. And so you can end up with misleading function names. Instead, just put a comment in the code.
Erm, yeah that's why this is a code smell. They aren't saying never have complex boolean expressions - just that if you do you'd better have a good reason because probably you'd be better off splitting it up into named parts.
callback hell - Not even a code smell. It’s an issue from back when languages like JavaScript didn’t support promises yet, but callbacks were popular.
Any specific ones? I've seen this before and I thought I would feel the same way as you before I read them, but actually the vast majority are pretty basic things that are not really arguable.
It's definitely nice to have a list like this to point inexperienced colleagues to in code reviews. It's a bit more authoritative than "trust me bro, I've written a lot of code".
I think the main thing that keeps me on GitHub is the network effect - all the other projects are there. They also have very generous (basically anti-competitive) free tiers.
That's the "say what you're going to say, say it, then say what you said" advice from school. It's ok if you don't know any better, or maybe for particularly boring work presentations, but it isn't a golden rule that most people blindly repeating it think it is.
Think about the best presentations you've seen. They never do that. They're engaging enough that you don't need repeat things three times.
The liquor store presumably? Just submitting patches is a simple 12 step process. I can't imagine the development and review process is any easier.
I have implemented a Git client from scratch which involved quite a bit of reading the Git source code. It's not bad code but it's definitely the sort of code that would break in all sorts of unexpected ways if you changed something. I wouldn't volunteer my time their tbh.