My comment game has gotten far better since I started doing live code reviews. Essentially I ask myself, “Would I feel the need to explain this to someone during a code review?” and if the answer is yes I add a comment.
Principal Engineer for Accumulate
My comment game has gotten far better since I started doing live code reviews. Essentially I ask myself, “Would I feel the need to explain this to someone during a code review?” and if the answer is yes I add a comment.
That’s a hot take. If you want your code to be maintainable at all, it needs comments. If you’re part of a team, write comments for them. If someone else may take over your project after you move on, leave comments for them. And have you ever tried to read uncommented code you wrote a year ago? Leave comments for yourself.
The key difference is that compilers don’t fuck up, outside of the very rare compiler bug. LLMs do fuck up, quite often.
Copilot frequently produces results that need to be fixed. Compilers don’t do that. Anyone who uses copilot to generate code without understanding how that code works is a shit developer. The same is true of anyone who copies from stack overflow/etc without understanding what they’re copying.
I’d create my own macro or function for that. I have enough ADD that I cannot stand boring shit like that and I will almost immediately write a pile of code to avoid having to do boring crap like that, even with copilot.
I have not and will not ever use AI generated code that I don’t thoroughly understand. If you properly understand the code you’re committing there shouldn’t be any damage. And beyond AI you should never commit code that you don’t properly understand unless it’s a throw away project.
I’ve run into that exact issue with copilot (deleting my tests). It is infuriating.
I don’t think I’d trust it to refactor code for me, not for anything important. I’d need to completely understand both the initial state and the result on a statement-by-statement level to be confident the result wasn’t secretly garbage and at that point I might as well write everything myself.
if you work in a shared codebase then PLEASE just follow whatever convention they have decided on, for the sake of everyone’s sanity.
That goes without saying; I’m not a barbarian.
“readability” is subjective. much like how there is no objective definition of “clean code”.
Did you not see the part where I said it’s less readable “in my opinion”?
i am insisting that people use a common standard regardless of your opinion on it.
I can read this one of two ways: either you’re making an assertion about what people are currently doing, or you’re telling me/others what to do. In the first case, you’re wrong. I’ve seen many examples of self-closed <br> tags in the open source projects I’ve contributed to and/or read through. In the second case, IDGAF about your opinion. When I contribute to an existing project I’ll do what they do, but if I’m the lead engineer starting a new project I’ll do what I think is the most readable unless the team overwhelmingly opposes me, ‘standards’ be damned, your opinion be damned.
The spec says self-closing is “unnecessary and has no effect of any kind” and “should be used only with caution”. That does not constitute a specification nor a standard - it’s a recommendation. And I don’t find that compelling. I’m not going to be a prima donna. I’m not going to force my opinions on a project I’m contributing to or a team I’m working with, but if I’m the one setting the standards for a project, I’m going to choose the ones that make the most sense to me.
If a spec tells me I should do something that makes my code less readable in my opinion I am going to ignore the spec every time.
GMT doesn’t have daylight savings but London does
I have no issue with their drivers working with their cards. I have issues using a proprietary, out of tree driver that taints my kernel and forces me to jump through hoops to get it to work whenever I recompile my kernel, which happens maybe once a month when Gentoo’s kernel source package is updated.
Also I use Wayland (because that’s what KDE defaults to).
I was an Apple fan for most of my life. And then Jobs died. The man was a huge asshole by all accounts but he sure knew how to design. Since then Apple has become just another tech giant making average products driven by business majors.
I’m about ready to rehome my RTX 2080 and get an AMD card so I don’t have to deal with Nvidia’s proprietary garbage or the shit-tier open source drivers.
Two cocktails will get me tipsy, two beers if they’re strong, but I can drink an entire bottle of vodka (over the course of 2-3 hours) without blacking out. Or at least I could in college, I’m not looking to try again.
That’s an artifact of JavaScript, not JSON. The JSON spec states that numbers are a sequence of digits with up to one decimal point. Implementations are not obligated to decode numbers as floating point. Go will happily decode into a 64-bit int, or into an arbitrary precision number.
hackthebox is essentially a puzzle solving platform where the puzzles are designed to teach you hacking. You’re not supposed to hack the platform.
It’s not just about learning a language. Given two equivalent languages, writing a project using one or the other is always going to be less work and less of a maintenance burden than writing it using both. A competent manager will take that into account when deciding what tools to use. On top of that, learning a new language has a cost. Of course Rust and JavaScript are not equivalent, but which one is ‘better’ is highly subjective and dependent on how you measure ‘better’. So a manager needs to take that into account. But my fundamental point is that using two languages for a project adds overhead, and learning a language adds overhead, so unless cost (including time) is irrelevant, there must be a compelling reason to choose a dual-language solution* over a single-language solution, and to chose a solution that requires your devs to learn a new language over one that does not. Not to mention switching platforms has a massive cost if your project is already mature. Even if you’re creating a new project, if your team already knows JavaScript and doesn’t have any particular objection to Electron, there’s no compelling reason.
If there is a good reason to learn a language then people will.
Sure. Except in my experience interviewing candidates and from what I’ve seen online, there are a lot of developers out there who aren’t very good. I am not optimistic that the average developer will have an easy time learning a new language. If the “we” in “Is this the electron alternative we’ve been waiting for” is you and I, that’s not a problem. But if OP meant to suggest there will be a large-scale shift away from Electron, then the average developer is quite relevant.
*As someone else pointed out, Dioxus is designed with the intent that you’ll right the frontend in Rust, so it’s not exactly dual-language like I thought.
Ah, well that’s great for folks who already know or want to learn Rust
I seriously doubt that a dual-language platform is ever going to supplant Electron. Electron has the major advantage that the entire app is written in one language. And according to Stack Overflow’s 2023 developer survey, 66% of devs use JavaScript, 45% use Python, 43% use TypeScript, and 12% use Rust. More devs use Java, C#, C++, PHP, and C than Rust. So 2/3 of developers wouldn’t have to learn a new language to use Electron, and only a small fraction of the remainder knows Rust.
Their rules have stopped me from being able to do my job. Like the time the AV software quarantined executables as I was creating them so I literally could not run my code. When security enforcement prevents me from working, something needs to change.