In Which @Captain asks C# Beginner Questions
-
@Captain said in In Which @Captain asks C# Beginner Questions:
No warnings for shadowed variables, apparently...
I get those, probably from resharper. You could probably build a syntax analyzer for it if you wanted and felt like it's worth the time. Even so I'd have used the
File
methods for IO. They're just simpler.
-
@Magus Yeah,
File.WriteAllText
was easy to use. It's just that I had already written the Sftp stuff and that uses streams, so I plugged into that.So what is this ReSharper thing? Is it worth getting?
-
@Captain These days no. However there is a 30day trial so there is no harm in trying it out.
-
@Captain and the main reason I'd say no is that once they integrated the new compiler, they added support for using it actively on your source files via syntax analyzers, which is how the suggestions and warnings in the current version work, even the built in ones.
-
Also pro-tip. VS2015 has about a million bugs. It possibly the worst version of VS since 2012. If strange things are happening.
- Kill it and re-open your project (2010-2013 had the same problem to a lesser extent).
- Look at the errors in the output window, not the error lists.
On larger projects I have heard devs say "oh visual studio is lying again".
-
@lucas1 Hmm, most of the bugs I run into lately seem to revolve around resharper breaking things.
-
@Magus If you have git running and are doing a merge or rebase it will have a fits. Sometimes it seems to lose permissions and won't copy dlls into the bin folder. There are loads of strange bugs. My favourite was with update one, if you added a new typescript file it wouldn't let you edit (even with a restart) until you had entered some text into the file via another editor.
-
@lucas1 Ah, I don't use git, so that could be why I haven't seen it. Which git addon are you using, so I can avoid it?
-
@Magus I am not using a git addon, I use the command line client with minitty. It might be the VS git client, but I turned most of that nonsense off. Also there is "vshub" process that spawns itself and runs it own http server.
-
@lucas1 So you turned things off and things were broken? I can hear the voice of blakey shouting through the ether.
-
@Magus Not quite. The VS git client I believes uses regular msysgit in the background as it asks you to install the 3rd party add-on on installation. I've had too many times iffy IDE git clients bolloxing up commits, I do it from the command line so at least it is my cockup rather than a bug in the tooling.
I think the only plugin I am running is one that adds indentation lines in the editor.
-
@Captain You can use Shift + F12 and F12 in VS to identify usages of variables and definitions respectfully.
-
Totally random question about the Microsoft ecosystem:
If I download the evaluation version of Windows 2012 R2 from https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2012-r2, can I use a valid license key to activate it permanently?
-
@Captain Probably, though I imagine wherever you have a valid key from has a way to download it.
-
@Captain Make sure it is the same edition as your key otherwise the keys definitely won't work.
-
@Captain said in In Which @Captain asks C# Beginner Questions:
@Magus It was a dumb bug with one variable shadowing another one. I had
result
defined as a static string and then I definedresult
inMain
and the wrong one was getting printed.No warnings for shadowed variables, apparently...
.NET recommends different naming convention for members than for locals. Good way to avoid shadowing in practice.
Properties are
PascalCase
and parameters/local vars arecamelCase
. For fields I use_prefixedCamel
.
-
@Captain said in In Which @Captain asks C# Beginner Questions:
So what is this ReSharper thing? Is it worth getting?
Very yes. Free licenses are available for students and FOSS devs, too.
-
@Captain said in In Which @Captain asks C# Beginner Questions:
So what is this ReSharper thing? Is it worth getting?
It's great if you like your VS to crash 5 times a day and get upset when it completes operations just too quickly sometimes.
-
@blakeyrat said in In Which @Captain asks C# Beginner Questions:
@Captain said in In Which @Captain asks C# Beginner Questions:
So what is this ReSharper thing? Is it worth getting?
It's great if you like your VS to crash 5 times a day and get upset when it completes operations just too quickly sometimes.
I remember when I got my new PC up and running and I spent a good half hour trying to figure out why my build wasn't building...
Turns out it was, just faster than I was willing to believe.
-
@error said in In Which @Captain asks C# Beginner Questions:
.NET recommends different naming convention for members than for locals. Good way to avoid shadowing in practice.
No it doesn't, you do. I in particular do not. My locals are a different color than members, and tell me when they're shadowing. If your tooling is inferior, it may help to do so, if you really can't come up with good names.
-
@Magus said in In Which @Captain asks C# Beginner Questions:
@error said in In Which @Captain asks C# Beginner Questions:
.NET recommends different naming convention for members than for locals. Good way to avoid shadowing in practice.
No it doesn't, you do. I in particular do not. My locals are a different color than members, and tell me when they're shadowing. If your tooling is inferior, it may help to do so, if you really can't come up with good names.
If you're not matching up with the naming conventions established by the .NET Framework API, you are and also TR.
-
@error There are no conventions for private members. By design. I read the thing! Nothing private is part of an API by definition anyway.
-
@Captain said in In Which @Captain asks C# Beginner Questions:
Totally random question about the Microsoft ecosystem:
If I download the evaluation version of Windows 2012 R2 from https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2012-r2, can I use a valid license key to activate it permanently?
This didn't work the last time I tried it. Evaluations versions are specifically built to not activate to other versions, through you might get away with a full in-place upgrade.
-
@error Methods are also supposed to be PascalCase. So if you weren't using VS that makes it easy to identify the difference you come down to naming conventions again, which for the most part are quite well explained in .NET.
Underscoring variables name is a VB.NET hangover, because VB.NET compiler (or whatever I don't do a lot of VB anymore) prefixes private members with an underscore, so a lot of devs tend to underscore to make it super obvious.
-
@lucas1 said in In Which @Captain asks C# Beginner Questions:
@error Methods are also supposed to be PascalCase. So if you weren't using VS that makes it easy to identify the difference you come down to naming conventions again, which for the most part are quite well explained in .NET.
I didn't mention methods because they weren't relevant. Methods aren't much at risk of being unintentionally shadowed.
@lucas1 said in In Which @Captain asks C# Beginner Questions:
Underscoring variables name is a VB.NET hangover, because VB.NET compiler (or whatever I don't do a lot of VB anymore) prefixes private members with an underscore, so a lot of devs tend to underscore to make it super obvious.
It's a great way to make it obvious when you're referring to a field and not a variable in order to avoid accidentally confusing the two (as @Captain did).
If it helps you avoid a bug, it's worthwhile typing that extra character. You shouldn't be referencing fields outside of properties anyway.
-
@error said in In Which @Captain asks C# Beginner Questions:
You shouldn't be referencing fields outside of properties anyway.
I swear you're getting progressively more insane. No. Fields are perfectly fine to access. Private fields are great.
-
@Magus said in In Which @Captain asks C# Beginner Questions:
@error said in In Which @Captain asks C# Beginner Questions:
You shouldn't be referencing fields outside of properties anyway.
I swear you're getting progressively more insane. No. Fields are perfectly fine to access. Private fields are great.
I've worked with a framework with virtual properties where overriding didn't work because all the methods referenced the private fields instead. Don't do that.
-
@Tsaukpaetra Shitty. I can't find the disc and the VLSC doesn't link to Windows Server downloads.
I lifted the key from the dead Windows Server 2012 R2 I decommissioned the other day.
I found some instructions on Microsoft.com, so I'll give it a try tomorrow.
-
@error said in In Which @Captain asks C# Beginner Questions:
I've worked with a framework with virtual properties where overriding didn't work because all the methods referenced the private fields instead. Don't do that.
You must be talking about something completely bizarre, but it certainly wasn't good design. Private fields are perfectly fine if you aren't completely stupid, which I'm becoming increasingly certain you are. Next you'll be telling us that goto is better than method calls...
-
@error said in In Which @Captain asks C# Beginner Questions:
@Magus said in In Which @Captain asks C# Beginner Questions:
@error said in In Which @Captain asks C# Beginner Questions:
You shouldn't be referencing fields outside of properties anyway.
I swear you're getting progressively more insane. No. Fields are perfectly fine to access. Private fields are great.
I've worked with a framework with virtual properties where overriding didn't work because all the methods referenced the private fields instead. Don't do that.
Because downvote:
I'm saying don't do this:
public class Foo { private Bar _bar; public virtual Bar Bar { get { return _bar; } set { _bar = value; } } public void DoStuff() { Something( _bar ); // don't do this } } public class MyFoo: Foo { public override Bar Bar { // DoStuff won't use this get; set; } }
All I'm trying to say is that with a little discipline you can avoid common pitfalls. Use names and practices that help you avoid subtle bugs like these. They're not arbitrary or cargo cult; they address real issues I've had to deal with.
-
TIL 'HyperV' has 'perv' in it.
-
@Captain said in In Which @Captain asks C# Beginner Questions:
TIL 'HyperV' has 'perv' in it.
That was one time!
Filed under: Oh. I see.
-
@error said in In Which @Captain asks C# Beginner Questions:
virtual properties
Bad idea in general in my book. I expect my properties to work just like fields, hiding some internal logic at best. Virtual dispatch on them is very much non-POLA.
-
@error said in In Which @Captain asks C# Beginner Questions:
@Captain said in In Which @Captain asks C# Beginner Questions:
TIL 'HyperV' has 'perv' in it.
That was one time!
Filed under: Oh. I see.
-
But it’s also specifically male childish humour. Puerile sniggering at breasts contributes to the continuing impression that software development is a boys club where girls aren’t welcome.
Chrissake, everything is gender war now.
Filed under: besides, it's not that girls aren't welcome, we're just stating the requirements to join
-
@error said in In Which @Captain asks C# Beginner Questions:
I'm saying don't do this:
Then say that, instead of saying "Don't use fields"! "Don't mess with a property's backing field" is fine. "Don't use fields" is completely stupid.
-
@Magus said in In Which @Captain asks C# Beginner Questions:
You must be talking about something completely bizarre, but it certainly wasn't good design. Private fields are perfectly fine if you aren't completely stupid, which I'm becoming increasingly certain you are.
Likewise if you think using the same naming convention for locals and members so they can be easily confused is a great idea. Or that circumventing the encapsulation of fields because laziness or "performance" is acceptable.
I work with a lot of shit code, most if it not mine. In my position, at least twice a day someone dumps a big broken pile of not-my-code in front of me and asks, "why it no work?"
95% of the time it's because of something stupid and trivial. 80% of the time it's something easily preventable through careful coding practices (not wearing a seat belt, if you will). I'm talking about typos, referencing a field when a variable was intended, sloppy use of inheritance, direct access of encapsulated data, etc...
Sure, the
_
prefix on private members is ugly. It should be! You're doing something ugly: you're tying your behavior to hidden state. The idea here is that accessing a field is something you opt in to.- Consider if your object really needs to be stateful
- No, really. Take a second look at 1. Can you move that state to a POCO somewhere, or maybe inject it in?
- Fine, you need state. Now it's your job to minimize the potential surface area.
Fields are for storing state. Properties are for encapsulating fields. If you do all your field accesses through properties, you avoid reliance on hidden behavior, and you protect yourself from future changes and refactoring gotchas.
If I can't tell what
Foo
method does because it depends on_foo
field, which is totally inaccessible to me, that's a shit design. If your methods are littered with direct access to hidden state, you're just waiting for some method somewhere to mishandle it slightly and introduce a bug that's a bitch to track down and fix. If only there was a convenient syntax to wrap field accesses so I didn't have to maintain this delicate state juggling act everywhere!
-
@error said in In Which @Captain asks C# Beginner Questions:
It's a great way to make it obvious when you're referring to a field and not a variable in order to avoid accidentally confusing the two (as @Captain did).
Lets pretend that "this" doesn't exist.
-
@error said in In Which @Captain asks C# Beginner Questions:
Likewise if you think using the same naming convention for locals and members so they can be easily confused is a great idea. Or that circumventing the encapsulation of fields because laziness or "performance" is acceptable.
They can't unless you really bother to do it.
-
@lucas1 said in In Which @Captain asks C# Beginner Questions:
@error said in In Which @Captain asks C# Beginner Questions:
It's a great way to make it obvious when you're referring to a field and not a variable in order to avoid accidentally confusing the two (as @Captain did).
Lets pretend that "this" doesn't exist.
Since there's no warning or error for omitting
this
, it may as well not for the purposes of avoiding bugs.It's fine that you can be careful and always type
this
. What about the six other guys on your team?
-
@error said in In Which @Captain asks C# Beginner Questions:
Since there's no warning or error for omitting this, it may as well not for the purposes of avoiding bugs.
Because it should be omitted when obvious.
And code review would catch this.
-
@lucas1 said in In Which @Captain asks C# Beginner Questions:
Because it should be omitted when obvious.
That's a dangerous habit. Consider someone may introduce a clashing variable name later. Now your code has silently changed behavior.
Sure, unit tests and code reviews catch bugs. Proper conventions avoid them altogether.
Filed under: An ounce of prevention is worth a pound of cure.
-
@error said in In Which @Captain asks C# Beginner Questions:
Fields are for storing state. Properties are for encapsulating fields.
This much of what you say is correct.
But private state is a thing, and gains no benefit from properties, and has nothing to do with encapsulation. This is why you sound stupid to me. I agree, naming is hard. I agree, tooling needs to be better. But magical underscores aren't going to save the day magically.
-
@error No it isn't, because it would break the build. It is a strongly typed language.
No the compiler will kick you in the balls.
-
@error Look, if you can't write code, you shouldn't be writing code. We're talking about the absolute basics of programming here.
-
@Magus said in In Which @Captain asks C# Beginner Questions:
@error said in In Which @Captain asks C# Beginner Questions:
Fields are for storing state. Properties are for encapsulating fields.
This much of what you say is correct.
But magical underscores aren't going to save the day magically.
They're not magical. We've already run into a real life case where a bug could have been avoided (@Captain's bug).
If they save me having to fix one bug a month, I've more than recouped all the lost time I spent typing
_
.
-
@error absolute bollox.
When people like you say that I know you don't actually use VS or C#. I know it is shite.
-
@error That was something tooling should be helping with. And it does, in my case. Otherwise, giving an actual, meaningful difference in names would have helped. An underscore is an excuse not to think about what you're doing, and you should be ashamed.
-
@lucas1 said in In Which @Captain asks C# Beginner Questions:
When people like you say that I know you don't actually use VS or C#.
Professionally since framework 1.1. I used to be a lazy sonuvabitch like you. Now I realize the time I "save" by sloppy practices, I will eventually repay with interest when I have to fix it later. It might not even be broken now, but that code is going to get touched at least a dozen more times after it's written. Someone's going to inherit from it in ways I don't expect. Someone's going to graft new features onto it. I might not even recognize it when they bring it back to me. But at least I don't need to worry that they assumed this field was a variable because the two were indistinguishable from one another.
It'll be because someone decided
GetFoo
should set_foobar
to true.
-
@error said in In Which @Captain asks C# Beginner Questions:
But at least I don't need to worry that they assumed this field was a variable because the two were indistinguishable from one another.
But not because you thought of a name, simply because you decided to take the easy way out and be sloppy.