gay transfemme nerd
over 21
please don't follow if you're under 18
avi 🎨: @VCRStatic
question for my programmer chosties: if you were forced to work in an object oriented language, would you prefer:
members within a class referred to directly by name, i.e.
// c#
class Foo {
int bar;
void bash() {
Console.WriteLine(bar);
}
}
or using something like self. or this., i.e.
// typescript
class Foo {
bar: int;
bash(): void {
console.log(this.bar);
}
}
(ignoring all other syntactical decisions between these two specific languages)
I prefer the former personally, but that's probably because my first language was java. I don't hate the latter but it can be annoying
i figure the latter is annoying but the former can be confusing, and i'm honestly not sure which is better
ideally the former, but the latter should be there as a just in case for whatever reason (eg. scoping conflicts)
i prefer the former with the option to use the latter if it needs to be disambiguated, which funny enough is how it works in C#!! (i usually imagine an invisible this. before accesses to the class's own members) but my brain thinks in C# by default so i'm biased
in places where I have the choice between the two (i.e. most of the Java code at my job) I slightly prefer the second to be more explicit / keep a consistent style, since a lot of setter functions or constructors will require "this" to be included anyways
I get so fed up with self. and this. being everywhere that I prefer the first one. but I concede I wouldn't love collaborating on sufficiently complex code without the added clarity that the second one provides
as someone who mainly programs in c# i'm used to "implicit this". however, if i were designing a language, i would actually require it to refer to a class's member, if only because i'd want to ensure that the scope of any given name is made clear. whether or not this is the reason you choose it is all on you lol
I used to like the former, but now that I've been mostly programming in non-OO languages, it's absolutely the latter.
Class fields are not variables (since e.g. mutating them has a wildly different effect than mutating a local variable), so please just be explicit about what they are.
latter. i need to know where my variables r coming from. everyone who says former is doing it for comfort reasons (i am doing it for comfort reasons too)
I'm old enough that I've come to believe that, if you can ever make something implicit...don't. It'll cause confusion downstream to someone at the worst possible time.
Sadly, that's not the trend in programming languages, because with editors and AI that handle most of the typing, programmers still somehow hate typing extra letters like they're still working on punch cards...
I try to exclusively use the latter. It makes the distinction between a field and a variable much more explicit and harder to misinterpret, and I generally think explicitness ought to win out over conciseness.
for classes that might have to interact with instances of themselves, the this-> prefix is highly appreciated. otherwise, I tend to just use the first, but even then I like to prefix member data with an underscore to keep things clear
If I had to choose between only these two possibilities and in the former, this is not allowed, then I'd prefer the latter. There are moments I want to be able to write this.foo = bar() to make it extra explicit that a non method-local thing is being mutated and if that means I have to spell it out everywhere else too, so be it.
That being said, in a lang that allows both, I usually write the former. Any decent Syntax highlighting will make it clear that this is an instance variable we're talking about here.
Btw in the former, if you can't write this, does that mean you just can't have a local var of the same name?
Edit: actually now that I think about it, in 99% of cases where I assign instance variables (constructors and setters) the method param is called the exact same, so I need to use this anyway. This is in java.
