curbstickle @ curbstickle @lemmy.dbzer0.com

Posts

4

Comments

1,035

Joined

1 yr. ago

While Hugh Jackman gets some sloppy dome (with a gun pointed to his head).

Its because he's the best there is folks.

Nope.

Ive got plenty of backlog, and virtually no time. At the current rate, I'll have plenty to play hanging out in hell.

Just garbage finally making its way out the door.

Just got my daughter operation for Christmas, played with the cards the very first time out.

So we haven't met, but ive definitely used the cards. Mousetrap I played with a lot, but I think only played by the full rules like maybe 10 times max.

"Adds a and b"?

Sure, not useful. Thats a what, not a why.

"Combined value needed for these outputs"

The "why". Useful. Shows the purpose, and explains the context it may be used in.

Assuming the "why" is known is the mistake - and one I see from junior and mid level, I dont care what language it is, its the same. Using refactoring code as an example, without context - the why - can cause problems. What may be more efficient for one resulting value being presented can cause issues for others (let's say precision as an example of why it could be a problem). Failing to include why something is being done is usually what introduces these problems, someone misses a different context than what they are looking at, and that belongs in a comment.

A comment on "why" isn't just important - for any block of code - it is, IMO, a requirement. I have and will continue to respond with "add comments as to why and resubmit".

"Won't You Be My Neighbor", Mister Rogers.

That really depends.

Especially for a function that may see use in a variety of scenarios.

I'm going to be firmly against anyone suggesting against proper comments - which, I'm sorry, but you are by your own statement.

Code will change for many, many, many reasons beyond just refactoring.

Edit: and why it was refactored is important as well.

There are just so many reasons, and yes, I will continue to be against this newer trend of "dont comment, make codes your comments".

All that is, is a great way to make your code harder to manage later. It doesnt take much effort to explain why you're doing something.

Not updating comments with code is what I'm talking about - that's not a comment problem, thats a programmer problem.

If they aren't updating the "why", that programmer is the problem, not comments.

I am going to disagree, comments should be an explanation.

The code is what's being done, a comment should be why its being done.

Go for it!

Also.... Reaper.

"Some people do a bad job commenting and updating comments, so lets not do comments" is not an approach that works for me.

Most of my code is at the prototype level. I'm concepting something out, usually paired with hardware.

If someone can't follow what I'm doing, its going to lead to problems. If a change happens to the hardware being controlled, code will not be good enough on its own.

Rather than being accepting of bad commenting practice, make comments (and updating them properly) part of good practice. In my experience, It saves time in the long run and leads to better code at the end.

As an extensive commenter, I completely agree.

I need to know wtf I was doing, making it convoluted to save a few lines is pointless.

It doesnt make a difference for the definition of a mass shooting (really any of them, there are multiple definitions).

Mod, not admin.

Mod is community level, admin is server level.

The majority accepted is 4 or more injured or killed, not including the shooter (gun violence archive).

The DOJ version is 4 or more killed, which is just the mass murder definition with a shooter, leaving out a lot of incidents.

In either case though, the motive is irrelevant because its not going to be known at the time.

It doesnt matter the reason, its still a mass shooting.

10 shot outside of a club in queens, ages 16-20

https://nypost.com/2025/01/02/us-news/at-least-10-wounded-in-mass-shooting-outside-queens-nightclub-sources/

I'm sure I'm wrong

I actually kinda think you're right, but like you I'm not looking into it any deeper.

I still have not switched back from Premiere and Resolve though. I don't trust them.

That is what a lot of folks are still saying (from my purely anecdotal experience).

I don't think macs are going away FWIW, just saying that its not at all necessary for the overwhelming majority of workflows I've come across. Especially with so many internal corp studios being happy with a blackmagic body in their kit.

35, so 8 years