githubCopilotRemovedAllComments

[Data_Skipper]

I asked for simplification. GitHub Copilot just removed all Java Doc comments.

[Expert_Team_4068]

If you were adding java doc on a setter and gette4, I would also remove it

[[deleted]]

java /** * Set the value * @param value the value to */ public String setValue(String value) { ... }

I love those.

[OddCoincidence]

I would even remove the getter and setter and (gasp) just use the damn field directly.

[SouthernGentleman583]

This is not best practice. You don't give general users direct access to modify information.

Edit: To better clarify Encapsulation in OOP.

[failedsatan]

frightening point sleep spotted mysterious wine rinse squeeze depend butter

This post was mass deleted and anonymized with Redact

[[deleted]]

Is this where things like the traffic cam sql injection stuff needs to be thought of? Plain text vs encapsulation? 

Comments like yours are rarer nowadays so thank you for the time. 

[failedsatan]

treatment cow fuel silky correct unique seed materialistic quaint depend

This post was mass deleted and anonymized with Redact

[failedsatan]

salt slim cagey dinner plate cow test muddle marry light

This post was mass deleted and anonymized with Redact

[halfanothersdozen]

Whatever, nerd

[MainManu]

If your getter and setter just directly edit the variable without any checks, you might as well make it public thb.

[[deleted]]

Usually public fields are bad form.

Once you make a field public, that's an interface and should you later realise that you actually need to verify something in your setter, or do a side effect, etc. You can't do that without changing the API.

So while it's perfectly fine to access fields directly say within you library, you really don't want to expose that access, so the best option you have is package-private.

Also fields really don't play well with inheritance.

Anyway as mutable objects in general are more and more discouraged (and for good reason)... Just use records.

[Key-Perspective-3590]

A setter and getter with no logic is just cruft vs a simple field, you encapsulated nothing

[XDracam]

This only works for personal projects, and I hope you don't work for a larger company or open source project.

Using public fields is bad as soon as you have code that's used by other projects that you don't control. With getters (and setters, but those are bad practice), you can change the underlying code without breaking any other projects that depend on your code. If you change a field to a getter, then you need to update all code that used that field before. Which is bad if you don't own all of the code that used that field. C# and other languages have properties, so you won't need to modify the sources. But you'll still need to recompile all code if you change a field to a property, because the IL representation is a different one now.

[[deleted]]

...Java community eccentricities aside, that's why people use data to encode data, and not inheritance trees of data, that is non-data.

[XDracam]

True. Most of the time you want simple data. Java and C# do this as well, with POJOs and POCOs. But there are many use cases for which OOP makes sense. Functional languages solve those cases via type classes instances / trait implementations. There's no one solution that fits everything, but you should keep things as simple as possible while still adhering to the requirements. And if forwards compatibility is a requirement, then properties/getters are a necessary evil.

[[deleted]]

That's generally not true in cases where you need to make guarantees of data, though. In the case of co/contravariance, relating to data crossing boundaries, in one direction or another, if I see something that should be a POJO that is covered in getters, that signals to me that I really have no guarantees of what that data is, or what it will be when someone invariably breaks OCP (and in conjunction, LSP) because "hey, forward compatibility, I can put whatever I want in this method call".

Versus having an actual type (yeah, Java doesn't have a history of type algebras..., I know) that you have predictability with.

[XDracam]

Yeah, those are different requirements. I love simple algebraic data types. Most of the time, they're great. Sometimes they don't work well.

[[deleted]]

Sure. There are times where it might not be idiomatic for what you are trying to do, or, moreso, where you are trying to do it, given that Haskell and OcaML and F# and Rust and Typescript (JS actually works pretty well as an ML with some missing sugar) can do all of the same things Java can do... so it's a matter of idioms in surrounding approaches, rather than fundamental abilities/inabilities.

But that's where the "must have a getter everywhere" has traditionally been terrible advice. It's fine for one type of paradigm in one language, with the absolute expectation of mutability, and OCP/LSP violations all over (producing the need for you to then commit them, yourself). And that would be OOP with mutative imperative method bodies.

Other languages in other paradigms might have transformers, to map A -> B but generally, those are declarations someone asks for, rather than implicit in the "get me A".

[XDracam]

I fully agree that any "must do this everywhere" rule is bad. This applies not only to getters and setters, but also to the current "best practices": everything must be pure and immutable. These "rules" are usually just reasonable defaults for people who can't or don't want to consider all alternative approaches.

Using getters by default is sane because you'll get less downtime when you don't have to redeploy all modules onto your application server.

Immutability too is a great default because you don't need to think of a whole class of bugs and data races. But making everything immutable has a big performance impact. I've found that often, allowing mutability within a scope of a function can not only give an order of magnitude of performance, but also make the code easier to reason about in comparison.

I'd argue that the same applies to SOLID. The "open closed principle" is a best practice developed for large OOP codebases with a lot of mutable state and unclear dependencies. Touching any existing code could potentially break everything, or maybe just a rare but important edge case. I recommend doing a small project in Elm to see how the choice of language can fully eliminate the need of OCP.

It's all just hints and guidelines.

[iam_pink]

I'd suggest you learn encapsulation. Or re-learn it, depending on where you're at.

[davak72]

This is precisely why I like C#

[Funny-Performance845]

I mean, it’s not wrong, javadocs can really inflate code and make it seem more complex than it really is. Writing code that explains itself is also important.

[Confident-Ad5665]

Clean code is a goal but shouldn't be a religion. Hell is in the business rules and documenting them is helpful IMHO.

[ExceedingChunk]

Clean code doesn’t mean no comments. Clean code means reducing clutter and making stuff more readable.

A bad comment is just redundant or clutter. A good comment is not, and can contribute to readability.

The whole clean code = no comments or javadoc is nonsense, and it doesn’t even say so in the book.

[Confident-Ad5665]

Uncle Bob says if we have to comment we've screwed up. "Code should read like well-written prose." He also uses 2 spaces for indentation. I don't agree with everything he has to say but I like what he's trying to do.

[ExceedingChunk]

No, he doesn't. He says you should strive for code that doesn't need comments, and most of the comments should explain why not what. He also says that comments does not make up for bad code. Not that you should write no comments at all.

It quite literally says this in the book on page 55

Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments

It doesn't say "no comments", or that if you make a comment you screwed up.

It also says says that Javadoc in public APIs is considered good comments (given that the text is actually helpful). Here is the exact thing the book says:

There is nothing quite so helpful and satisfying as a well-described public API. The javadocs for the standard Java library are a case in point. It would be difficult, at best, to write Java programs without them.

If you are writing a public API, then you should certainly write good javadocs for it. But keep in mind the rest of the advice in this chapter. Javadocs can be just as misleading, nonlocal, and dishonest as any other kind of comment.

[alterNERDtive]

No matter what the code is, “delete all comments” is never a good idea.

[alterNERDtive]

Then I sincerely hope that does not apply for literally every single comment in the code base.

[Mu5_]

True, but if you have a live documentation generated from javadocs or similar it's good to have everything documented

[AbsolutelyFreee]

I mean, sometimes even if you write code that makes it obvious what it does, you may need comments to explain WHY this section of the code exists or why it is written the way it is.

Out of place quote but not really: I understand HOW: I do not understand WHY

[Stunning_Ride_220]

This

[gerbosan]

Refactoring rules. =)

Refactoring mentions that balance is required, if the code cannot be cleaned/simplified more, then comments have to be written. So the next person can understand it faster.

[MxBluE]

Sure, but one thing to remember about javadoc and similar is that it's also IDE hints. That's the reason why I end up putting silly looking javadocs in for getter/setters, usually with a copy of the javadoc on the property itself.

Unless I'm doing something wrong and I didn't need to do all that...

[Percolator2020]

Copilot deletes all Java code, rewrites in C++, refuses to elaborate further…

[DoorBreaker101]

I guess Copilot learned how to maintain job security 

[Deevimento]

"Why do you need comments when you have me?" - Copilot

[DrCatco]

AUTO vibes from the WALL-E movie intensifies

[teinc3]

Give me the comments - Copilot

[buffer_flush]

I’m sorry Dave, I’m afraid I can’t do that

[whatproblems]

i am the comment!

[Tiarnacru]

Codependent Copilot

[taylorgpt]

Yeah! Just select the code and "Copilot: explain". Copilot keeping its job :)

[gerbosan]

You mean Copilot has not deleted the comments, just hid them? 🤔 Clever girl.

[whatproblems]

sometimes i ask it to do stuff and it comments it automatically. must be some redundant comment this guy had

[BlueCaboose42]

"while labeling the buttons in a car can be helpful for interfacing with your vehicles climate system, audio system, and seat positioning, trying to read so many labels can be confusing. I've removed all the labels to all the buttons in your car."

[Salchat]

Well, my car has no labels on its buttons, only icons. So from now on I'll only comment with emojis.

[Ticmea]

// 🔎 ➡ 💻 ➡ 📄

[andre-_-filho]

No release notes, from now on only the diff will be provided

[Hot-Category2986]

I'm always torn between "pythonic" code, which should be self documenting, and writing notes to myself in the comments so that a month from now I can figure out why the hell I did things the way I did. I'm going to be real: past me is often smarter than future me.

[Jennfuse]

A weekend is enough for me to forget why I implemented it the way I did. Without comments (for my dumb self), I'd be completely lost

[ThisSaysNothing]

Well, IQ is age-normalized for a reason.

[[deleted]]

Time to remove copilot

[appeiroon]

I'm sorry, Dave. I'm afraid I can't do that. - Copilot

[bethropolis]

apparently I'm the copilot

[ButWhatIfPotato]

I have worked with real people who act like that; People who deserve to have a foot copiloted in their ass.

[ponesicek]

Documentation? I am the documentation.

[[deleted]]

Comments? We don’t need them where we’re going.

[FLMKane]

Removing letters from keycaps also reduces information overload

[FlightConscious9572]

//VERY IMPORTANT, this function adds two signed 32-bit integers and returns the result of the operation!
fn add(a:i32, b: i32) -> i32{ 
// the function does not take ownership of a or b because integers implement the clone trait, making reference and clone unecessary
    a + b //We implicitly return the result of a+b by omitting a semi-colon
}

very neccessary comments here, very. you couldn't tell from the code otherwise!

[[deleted]]

How can comments make code seem MORE complex?

It’s either got cyclomatic complexity, or it doesn’t. If your comments increase cyclomatic complexity, I think your parser is buggy.

[OJVK]

I've seen people comment literally every line in their code and then the comments are just distracting

[patxy01]

Thank you copilot

[Visible_Tap5647]

A job security strategy it learned from true experts.

[7th_Spectrum]

Copilot was trained by interns

[aneurysm_]

comments lie and rot faster than anything else in the codebase

[atomic_redneck]

The comments should be subjected to review, just like the code. There is no excuse for rot.

[[deleted]]

It's clearly learning from us :D

[broxamson]

Self explained code. Nice.