9 ms·

>I've had coworkers who would put this before every method call, because...? When calling your own method, in your own class, that inherits/implements no other

by nend 6y ago

>I've had coworkers who would put this before every method call, because...? When calling your own method, in your own class, that inherits/implements no other classes, why on earth would you decorate your own method call with this? Because it's consistent with the pattern of [object].[method](). When you call a method in class B from class A, the call is b.someMethod(). When you call a method in class A from another method in class A, the call is this.someMethod(). I personally find that the consistency makes the code easier to parse and read. If I join an existing project where "this" isn't being used already, I wouldn't push it. As long as your consistent either way it's not a big deal, but for new projects where I get a say in it, it is my preference.

OskarS 6y ago
Yeah, I don't usually include "this" when calling methods on the same object, but it's not like it enrages me or anything. I totally get why you would, and it's fine. I generally agree with "consistency is good", but for an issue like this: honestly, who cares? This is SUCH a small difference that even if you're inconsistent, I doubt I'd even notice it or pay it a second thought. If you're going to work with other human beings, you can't be this insanely dogmatic, you'll never get anything done.
asdfman123 6y ago
I'm just here to say I'd much rather see composition used over inheritance and I don't see a good case for inheritance in most business applications.
- tonyedgecombe 6y ago
  If you are using Windows Forms or WPF with C# then you will have to deal with it.
- derefr 6y ago
  I really like Golang's choice to not offer inheritance, but instead an alternative: embedding. Which is really just composition, but where 1. the child is named implicitly after its type, and 2. its methods and members are automatically promoted to visibility in the "namespace" of the parent (but still "live in" the child.) So, if you've got Go code like this: type B struct { int c } type A struct { B } ...then if you type `anA.c`, it's basically the same as if you had written `anA.B.c`. It's just sugar. And, as with inheritance, members+methods defined explicitly on the parent (A) shadow the ones from the child (B), when you're accessing them on the parent. So you can do something that looks a lot like "subclass method overriding" on the child. (Though it isn't, quite, because the embedded child's methods, once reached, will only call each-other, oblivious to the parent. In C++ terms, there are no "virtual" methods.) This is more often used for decoration or aggregation (e.g. Go's bufio.ReadWriter, which is just a struct embedding a bufio.Reader and a bufio.Writer), but it can be used to simulate inheritance pretty well, with almost none of the disadvantages that come from having inheritance built into your type system. (For example, there's no need for the Liskov Substitution Principle in Golang, since you can't pass an embedding "subclass" (A) instance into a method parameter that wants the "base class" type (B). If you want that behavior, you opt into it explicitly by defining the method parameter as being of an interface type, where the interface is one that B implements; then, anything that embeds B will—unless it shadowed B's methods with methods of different signatures—also meet that interface.)
- 0xffff2 6y ago
  What on earth does this have to do with the topic at hand? There are plenty of places where composition/inheritance have been discussed and will be discussed. It doesn't need to be brought up every single time someone mentions a language that supports OOP.
jodrellblank 6y ago
> When calling your own method > decorate your own method > I personally find that the consistency makes the code easier to parse and read. > As long as your consistent knowing when to break consistency is a sign of education and superiority. The point of it is to be difficult, to make those who know identifiable and part of a club, whether the club is grammar nazis or, well, grammar nazis. If only we could make a push to regularize and consistentize more things, without it being called "dumbing down" or "satire".
- jodrellblank 6y ago
  -4 votes. HN must really hate suggesting that minor distinctions that do nothing to help and are only kept in the world to prove you know them, are a waste. Or didn't read my comment.
  - pmiller2 6y ago
    You know what HN hates more than "suggesting that minor distinctions that do nothing to help and are only kept in the world to prove you know them, are a waste?" Complaining about downvotes. Yes, there is a reason the saying "a foolish consistency is the hobgoblin of little minds" is a thing. (Incidentally, it's a quote from Ralph Waldo Emerson.) But, my experience, and that of many others is that having a consistently styled codebase makes things a lot easier when making changes later. Yes, there are tradeoffs, but, in engineering, we learn to figure out which tradeoffs are worth making. That's the point people are trying to make, and it is not a trivial one. Edit: also note the word "foolish" in this context. "Foolish consistency" would be taking the consistency principle to levels where it no longer provides benefits.
    - jodrellblank 6y ago
      So we're agreed that consistency is a good thing, and that making things easier is good? Why are you saying it in the style of disagreeing? > Complaining about downvotes. I'm not complaining about downvotes, I'm accusing people of not reading. I think people saw my comment as pointing out the wrong "your" and reflexively downvoted it. I'm prompting people to see that's not the case.
throw1234651234 6y ago
It's superfluous.
- masklinn 6y ago
  That it's technically superfluous doesn't mean it's practically useless.
  - velox_io 6y ago
    How did the article not mention extension methods, when that's arguably the only true use case (many are against such methods). I'm a big C# fan, I like a lot about the language, but the inheritance is especially cumbersome and it can become a minefield for the uninitiated. It's only something you avoid when you have tripped by it. The biggest minefield is when using them in initializers, but I'm pretty sure the compilar has displayed warning for sometime and I believe Resharper has had it forever (.net 3.5?). The only legitimate uses of 'this' is when is when using indexers and when using 'this' as the first parameter in extension methods. Nothing else springs to mind, and as mentioned above, 'base' should normally be used in indexors. However, there are times when I have used it for readability (which could be considered as an antipattern). I guess this is an example of why languages become so complex. Semantic sugar everywhere (it's addictive!) Extention Methods https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
- rcoveson 6y ago
  soiswhitespaceinmanylanguages
- draw_down 6y ago
  Everything besides what remains after you run a minifier is superfluous. (Which is more of a JS thing, but bear with me.) Lots of reasons we don’t write code that looks like that.
bfrydl 6y ago
I adopted this style after working in TypeScript for a while and then going back to C#. I came to really like having an explicit receiver on every function. I work in a lot of languages where that's required, such as TS and Rust, and now the “normal” C# style of calling a method without receiver is confusing. Also lots of people love to add _ or m_ before fields to distinguish them from local variables, so why not just use `this.`? I think once you actually use this style it starts to make a lot more sense.
- throwaheyy 6y ago
  It's a lot easier to visually scan for _ than for 'this.', quicker to read code that uses _, and it's about 5 times quicker to type.
  - bfrydl 6y ago
    I personally think reasons like this are just pulled out of thin air to justify simple style preferences. For example, `this` is an entire word that the editor draws in a different color, so it seems unlikely that `_` is easier to scan for. Even I'm not claiming to have objective reasons for preferring `this`.
travisgriggs 6y ago
This. So this. So very this. Color me odd, I did do 20+ years of Smalltalk, that weird "objects all the way down" language where self was not an option. What I have observed anecdotally over the the last 10 years as I've become much more of a polyglot is that, very generalisticaly speaking, spheres that frown on self/this produce code that is less "objecty" than otherwise. Spheres that eschew it's use often feel like just simpler C. And to be honest, that's fine. If you thing object oriented programming is just about "better organizing/structuring" your code, then do the ALGOL style thing. But if you want to have that "my God, it's full of objects" experience, try being explicit with your message sends.
T-hawk 6y ago
I do a middle ground: I use "this" for a method call specifically when the call is occurring within the context of an instantiation of a class. As opposed to a static method calling a static method, where the method name goes unprefixed, because there is no object that would be represented by "this" (and C# doesn't even allow it.) Curious how you would think of this approach. Would you call that inconsistent, or a useful separation of thought patterns?
- kmonsen 6y ago
  inconsistent
stefanandcode 6y ago
I also like seeing if a method is static or not at a glance.

by nend 6y ago

OskarS 6y ago

Yeah, I don't usually include "this" when calling methods on the same object, but it's not like it enrages me or anything. I totally get why you would, and it's fine. I generally agree with "consistency is good", but for an issue like this: honestly, who cares? This is SUCH a small difference that even if you're inconsistent, I doubt I'd even notice it or pay it a second thought. If you're going to work with other human beings, you can't be this insanely dogmatic, you'll never get anything done.

asdfman123 6y ago

I'm just here to say I'd much rather see composition used over inheritance and I don't see a good case for inheritance in most business applications.

tonyedgecombe 6y ago
If you are using Windows Forms or WPF with C# then you will have to deal with it.
derefr 6y ago
I really like Golang's choice to not offer inheritance, but instead an alternative: embedding. Which is really just composition, but where 1. the child is named implicitly after its type, and 2. its methods and members are automatically promoted to visibility in the "namespace" of the parent (but still "live in" the child.) So, if you've got Go code like this: type B struct { int c } type A struct { B } ...then if you type `anA.c`, it's basically the same as if you had written `anA.B.c`. It's just sugar. And, as with inheritance, members+methods defined explicitly on the parent (A) shadow the ones from the child (B), when you're accessing them on the parent. So you can do something that looks a lot like "subclass method overriding" on the child. (Though it isn't, quite, because the embedded child's methods, once reached, will only call each-other, oblivious to the parent. In C++ terms, there are no "virtual" methods.) This is more often used for decoration or aggregation (e.g. Go's bufio.ReadWriter, which is just a struct embedding a bufio.Reader and a bufio.Writer), but it can be used to simulate inheritance pretty well, with almost none of the disadvantages that come from having inheritance built into your type system. (For example, there's no need for the Liskov Substitution Principle in Golang, since you can't pass an embedding "subclass" (A) instance into a method parameter that wants the "base class" type (B). If you want that behavior, you opt into it explicitly by defining the method parameter as being of an interface type, where the interface is one that B implements; then, anything that embeds B will—unless it shadowed B's methods with methods of different signatures—also meet that interface.)
0xffff2 6y ago
What on earth does this have to do with the topic at hand? There are plenty of places where composition/inheritance have been discussed and will be discussed. It doesn't need to be brought up every single time someone mentions a language that supports OOP.

jodrellblank 6y ago

> When calling your own method > decorate your own method > I personally find that the consistency makes the code easier to parse and read. > As long as your consistent knowing when to break consistency is a sign of education and superiority. The point of it is to be difficult, to make those who know identifiable and part of a club, whether the club is grammar nazis or, well, grammar nazis. If only we could make a push to regularize and consistentize more things, without it being called "dumbing down" or "satire".

jodrellblank 6y ago
-4 votes. HN must really hate suggesting that minor distinctions that do nothing to help and are only kept in the world to prove you know them, are a waste. Or didn't read my comment.
- pmiller2 6y ago
  You know what HN hates more than "suggesting that minor distinctions that do nothing to help and are only kept in the world to prove you know them, are a waste?" Complaining about downvotes. Yes, there is a reason the saying "a foolish consistency is the hobgoblin of little minds" is a thing. (Incidentally, it's a quote from Ralph Waldo Emerson.) But, my experience, and that of many others is that having a consistently styled codebase makes things a lot easier when making changes later. Yes, there are tradeoffs, but, in engineering, we learn to figure out which tradeoffs are worth making. That's the point people are trying to make, and it is not a trivial one. Edit: also note the word "foolish" in this context. "Foolish consistency" would be taking the consistency principle to levels where it no longer provides benefits.
  - jodrellblank 6y ago
    So we're agreed that consistency is a good thing, and that making things easier is good? Why are you saying it in the style of disagreeing? > Complaining about downvotes. I'm not complaining about downvotes, I'm accusing people of not reading. I think people saw my comment as pointing out the wrong "your" and reflexively downvoted it. I'm prompting people to see that's not the case.

throw1234651234 6y ago

It's superfluous.

masklinn 6y ago
That it's technically superfluous doesn't mean it's practically useless.
- velox_io 6y ago
  How did the article not mention extension methods, when that's arguably the only true use case (many are against such methods). I'm a big C# fan, I like a lot about the language, but the inheritance is especially cumbersome and it can become a minefield for the uninitiated. It's only something you avoid when you have tripped by it. The biggest minefield is when using them in initializers, but I'm pretty sure the compilar has displayed warning for sometime and I believe Resharper has had it forever (.net 3.5?). The only legitimate uses of 'this' is when is when using indexers and when using 'this' as the first parameter in extension methods. Nothing else springs to mind, and as mentioned above, 'base' should normally be used in indexors. However, there are times when I have used it for readability (which could be considered as an antipattern). I guess this is an example of why languages become so complex. Semantic sugar everywhere (it's addictive!) Extention Methods https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/extension-methods https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
rcoveson 6y ago
soiswhitespaceinmanylanguages
draw_down 6y ago
Everything besides what remains after you run a minifier is superfluous. (Which is more of a JS thing, but bear with me.) Lots of reasons we don’t write code that looks like that.

bfrydl 6y ago

I adopted this style after working in TypeScript for a while and then going back to C#. I came to really like having an explicit receiver on every function. I work in a lot of languages where that's required, such as TS and Rust, and now the “normal” C# style of calling a method without receiver is confusing. Also lots of people love to add _ or m_ before fields to distinguish them from local variables, so why not just use `this.`? I think once you actually use this style it starts to make a lot more sense.

throwaheyy 6y ago
It's a lot easier to visually scan for _ than for 'this.', quicker to read code that uses _, and it's about 5 times quicker to type.
- bfrydl 6y ago
  I personally think reasons like this are just pulled out of thin air to justify simple style preferences. For example, `this` is an entire word that the editor draws in a different color, so it seems unlikely that `_` is easier to scan for. Even I'm not claiming to have objective reasons for preferring `this`.

travisgriggs 6y ago

This. So this. So very this. Color me odd, I did do 20+ years of Smalltalk, that weird "objects all the way down" language where self was not an option. What I have observed anecdotally over the the last 10 years as I've become much more of a polyglot is that, very generalisticaly speaking, spheres that frown on self/this produce code that is less "objecty" than otherwise. Spheres that eschew it's use often feel like just simpler C. And to be honest, that's fine. If you thing object oriented programming is just about "better organizing/structuring" your code, then do the ALGOL style thing. But if you want to have that "my God, it's full of objects" experience, try being explicit with your message sends.

T-hawk 6y ago

I do a middle ground: I use "this" for a method call specifically when the call is occurring within the context of an instantiation of a class. As opposed to a static method calling a static method, where the method name goes unprefixed, because there is no object that would be represented by "this" (and C# doesn't even allow it.) Curious how you would think of this approach. Would you call that inconsistent, or a useful separation of thought patterns?

kmonsen 6y ago
inconsistent

stefanandcode 6y ago

I also like seeing if a method is static or not at a glance.