Correcting the reviewer.
Notes: “should of” isn’t valid, should implies a verb, of isn’t a verb. I expect you meant “should have”. Please recall this in future submissions.
A question mark does not fit the sentence, which is a statement (“they should.” rather than “should they?”). While question marks are commonly used to demonstrate a rising tone at the end of a sentence, its not considered correct for formal writing.
A-ha, but this most decidedly not formal writing! UNO REVERSE CARD.
But on a more serious note, I did intend it as a sort of question because I’m not 100% sure, because the rules for quote use might well be different in English than my native language. I actually also don’t know the rule for question mark usage in English; is it generally considered a crime against orthography to plonk a question mark on something that’s a statement, or is it valid in some cases?
It’s totally valid in most cases. It’s technically only supposed to be used for a question, but language is based on how it’s most commonly used, with those “rules” only applying in extremely formal situations. With the prevalence of informal text-based communication, many people use it to indicate being unsure, like how you used it. I just wanted to continue the chain of grammar corrections (which is why I used the wrong “its”/“it’s” at one point). Also, you were right about the quotes.
It’s technically only supposed to be used for a question, but language is based on how it’s most commonly used
Ah, I see you’re also a descriptivist 😀
But yeah I know you were just continuing the joke; I’m a language nerd (well, general nerd really) and I just got curious about what the rule actually is. While English orthography rules related to punctuation usually seem to be pretty much the same as with Finnish, the rule for question marks seems to be more relaxed in Finnish because it can “officially” be used to mark any expression as a question. The rules for commas are also different, ours are closer to German and we tend to spray commas everywhere
They should of course keep that in mind, but it’s not that “should” should always be followed by a verb directly. The problem is that “of” in this context is a mishearing/spelling of “have”, so they should in this case have written it like that instead.
I would argue that “should of” is just a naive written rendition of the spoken contraction “should’ve”. They are homophones, so it’s a completely understandable error among those without the relevant education or background. I know only English and was in Grade 9 at a different school before someone corrected me.
In that spirit, I will call attention to your first sentence, specifically the comma. In my opinion, that can be improved. One of three other constructions would be more appropriate:
I am really happy when people are quite strict in code reviews. It makes me feel safer and I get to learn more.
I am really happy when people are quite strict in code reviews, because it makes me feel safer and I get to learn more.
I am really happy when people are quite strict in code reviews; it makes me feel safer and I get to learn more.
The first of my suggested changes is favoured by those who follow the school of thought that argues that written sentences should be kept short and uncomplicated to make processing easier for those less fluent. To me, it sounds choppy or that you’ve omitted someone asking “Why?” after the first sentence.
Personally, I prefer the middle one, because it is the full expression of a complete state of mind. You have a feeling and a reason for that feeling. There is a sense in which they are inseparable, so not splitting them up seems like a good idea. The “because” explicitly links the feeling and reason.
The semicolon construction was favoured by my grade school teachers in the 1960s, but, as with the first suggestion, it just feels choppy. I tend to overuse semicolons, so I try to go back and either replace them with periods or restructure the sentences to eliminate them. In this particular case, I think the semicolon is preferable to both comma and period, but still inferior to the “because” construction.
I’ve clearly spent too much time hashing stuff out in writers’ groups. :)
I agree with most of that. In formal settings, I prefer full sentences with conjunctions; however, choppy sentences are the ones that often end up in my Lemmy comments.
Reviews have to be balanced to circumstance. There is a big difference between putting out the sales brochure and the notice on the bulletin board. Likewise in coding a cryptographic framework for general consumption and that little script to create personal slideshows based on how you’ve tagged your photos.
As a general rule, wider distributions, public distributions, and long-lived distributions need more ambitious reviews. If the distribution is wide, public, and permanent, then everything needs very detailed scrutiny.
I have found some success in starting with and occasionally revisiting review goals. This helps create and maintain some consistency in a process that is scaled to the task at hand.
Notably, a good code review should also bring up the good parts of the submission, and not just concentrate on the errors. Not only does it make the recipient feel better to get positive feedback among the negative, but it helps them learn about good practices too. Just concentrating on the errors doesn’t really tell them which things they’re doing well.
Many reviewers concentrate on just finding mistakes, and while it’s useful it’s sort of the bare minimum; a good code review should be educational. Especially if the submitter’s a more junior coder, in which case it’d also be a good idea to not just outright tell them how you’d fix some problem, but sort of lead them to a solution by asking them questions and pointing things out and letting them do the thinking themselves. But still, experienced coders will also benefit from well-structured feedback, it’s not like we’re “finished” and stopped learning.
Yes, I tend to do that, and thankfully some of my colleagues do too. Clever but readable solutions, following good and relevant practices, clear documentation, making a good MR description that makes it easier to review, and more.
That’s great to hear. It’s thankfully becoming more common in general, and we can all do our part in spreading these practices.
I tended to actively evangelize for it when I was managing coders or teams. Unfortunately it’s still not all that uncommon for coders to be downright offensive when giving feedback, like not necessrily quite Linus-level rants but things like “this is idiotic, this is stupid, that’s shit, why would you do that” etc etc. The usual explanation I’ve gotten is that they’re just being “honest” and saying what they think, and it’s not their problem if the reviewee (is that even a word‽ I can’t English today) gets offended. Some even get all huffy about it, like “oh we’re just supposed to coddle them and never say anything negative so their little feefees don’t get hurt?” And I mean, yeah, getting honest feedback definitely a good way to learn, but it’s not like the only way to point out errors or problems is to be a cunt about it.
Assuming you have competent leadership, then it wouldn’t be merged if you missed something obvious. I guess you’re saying that you want more positive reinforcement.
Yeah, I learn so much from code reviews and they’ve saved me so much time from dumb mistakes I missed. I’ve also caught no shortage of bugs in other people’s code that saved us all a stressful headache. It’s just vastly easier to fix a bug before it merges than once it breaks a bunch of people.
I literally cannot comprehend coding with ChatGPT- How can I expect something to work if I don’t understand it, and how can I understand it if I don’t code and debug it myself? How can you expect to troubleshoot any issues afterwards if you don’t understand the code? I wouldn’t trust GPT for anything more complex than Hello World.
Just yesterday, I wrote a first version of a fairly complex method, then pasted it into GPT-4. It explained my code to me clearly, I was able to have a conversation with it about the code, and when I asked it to write a better version, that version ended up having a couple significant logical simplifications. (And a silly defect that I corrected it on.)
The damn thing hallucinates sometimes (especially with more obscure/deep topics) and occasionally makes stupid mistakes, so it keeps you on your toes a bit, but it is nevertheless a very valuable tool.
That only really works, if the method is self-contained, and written in a language that GPT has seen often (such as python). I stopped using it, because for 1 in 10 successful tries I waste time for the other 9 tries…
If I’m writing something slightly more complex, ChatGPT(4) is mostly failing.
If I’m writing complex code, I don’t even get the idea of using ChatGPT, because I’m only getting disappointed, and in the end waste more time trying to “engineer” the prompt, only to get disappointed again.
I currently cannot imagine using ChatGPT for coding, I was excited in the beginning, and it’s sometimes useful, but mostly not really for coding…
If you’re already knee deep in existing code and looking for bugs or need to write quite specific algorithms it seems not very useful. But if you for some reason need to write stuff that has the slightest feeling of boilerplate, like how do I interact with well established framework or service X while doing A, B C it can be really useful.
Also it’s often doing a great job if you paste a stack trace into it and maybe some surrounding code. I used it to fix someone else’s Java code as well as to upgrade some 3rd party Wordpress junk to latest PHP. I barely know Java and stopped following PHP news around version 5.6.
You shouldn’t use code that you don’t understand. Chatgpt outputs quite readable and understandable code and makes sure to explain a lot of it and you can ask questions about it.
It can save quite a lot of effort, especially for tasks that are more tedious than hard. Even more if you have a general idea of what you want to do but you’re not familiar with the specific tools and libraries that you want to use for the task.
It’s also wrong a lot. Hence the requirement for understanding. It can be helpful to get through a stretch but it will fuck up before too long and relying on it entirely is a bad idea.
Often the code is self explanitory. I understand the code very often, but I still couldn’t write it correctly from scratch. You never feel like that?
This is how code examples in books works too. You get some code to look at and try to understand it. Otherwise it’s like you would ignore code examples while learning programming.
I haven’t been in web development in over 20 years; thanks to ChatGPT, I was able to get up-to-speed and start building websites again, when in the past I would have never been able to do so.
GPT is a powerful tool that can allow anyone to do anything if they’re willing to put in the effort. We should be praising it, not making fun of it. It’s as revolutionary as the internet itself.
I use it to give me prototypes for ansible because Ansible is junk. Then I build my stuff from the mishmash and have GPT check it. Cuts a lot of time down that I’d rather be doing any-bloody-thing else with.
ChatGPT was never made for programming and is horrible at generating code. It is nice for a peer-programming kinda setup tho, because it can quickly point you towards tools, libraries, APIs etc. to use
You can always revert (i.e. undo in a new commit) the faulty commit. That will keep the history. This meme is not just about pushing straight to master, it’s about push --force which overwrites the remote branch completely, changing history.
Sometimes there’s only the nuclear option left, I have only done it a few times, someone merged a major refactoring and we ended up reverting by changing history.
I have also observed that when you revert with git revert and then merge back some time later git can get confused about if a commit was merged or not.
Mind you we didn’t use git flow or other smart processes to our own regret.
git can get confused about if a commit was merged or not.
You have to revert the revert before re-merging the branch. Otherwise git keeps track of the commits that you reverted and doesn’t apply them ever again.
Prescriptivism is mostly just an unprincipled mishmash of shibboleths someone pulled out of their rear end hundreds of years ago, classism, and knee-jerk reactions against language change.
For example - why do people distinguish less vs fewer to refer to countable vs uncountable nouns? Because someone wrote in 1770 that they thought that distinction was elegant, despite not actually reflecting the way English at the time was spoken.
Why is ain’t “not a word”? Because it originated in the speech of poor people, and was used less commonly by rich people. People roll their eyes at new business-speak because it comes from rich, powerful people, but look down their nose at language innovations from poor hillbillies and other disfavored groups.
And you can find writings from old prescriptivists complaining about literally every change in the language, such as hating the new ambigious use of singular ‘you’ when ‘thou’ was perfectly good and unambiguous or hating phrases like ‘very pleased’.
Nah, they’re the one who’s contributing most to the project. Mostly because their code is so garbage no one else can work with it. But that’s not a thing the managers take into account.
This shit happened the other week for me. Senior dev pushed the shittiest JS code without testing the day of a production install and it caused us to have to roll back the install after it very predictably caused a bunch of crashes for pages on our public site. Worst part is, the entirety of what he wrote could’ve been implemented as a CSS media query
Notepad++ is perfectly fine to code in. With the wealth of plugins it has, it’s pretty similar to vscode in how you can trick it out with all sorts of things it can’t do by default.
I’m a tolerant person, but come on, man. Between VSCode, JetBrains, (n)vim and emacs, and I can’t think of a legitimate reason to use np++ for development over any of them.
I don't use JetBrains because it's not free, I mainly use VSCode since it is and works fine, but I would use np++ after that. I spent years working in np++.
I played with linux in the early '90s, but mostly got started on GenToo Linux years ago and they had people installing Nano when building from the ground up. I grew to like that and never really learned VIM. I did use emacs every now and again, but all of those have lots of unwieldy key combinations that require memorization and don't work like a lot of other programs people coming from, for instance, Windows would be at all familiar with. The barrier to entry was too high to bother with so it was wine and np++ since I was also still using Windows for work.
I've been forced to use a Mac for work for the last almost-year and still can't find anything as good as np++. BBCode is as close as I can get and I'm still not really a fan.
Macros man, being able to record a macro and use it quickly and easily is worth it’s weight in gold when you’re doing something super repetitive that there are no automatic refactors for.
And i hate the “modern sleek design” culture of making all the options hidden and difficult to reach. Notepad s interface is so fucking clean and usefull.
I still use intellij because of a lot of other things but quite often I find myself using notepad for specific tasks and it’s such a treat
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.