|
Dolemite posted:Yeah, I definitely saw lambdas all over the place within the codebase at the last company. Oddly, I never once saw any lines of code containing Action<T1, T2> or Func<T, TResult>. Took a look at the C# reference docs and these are interesting. They're referred to as delegates, which makes sense. The way Action and Func are used in the code samples, it's almost like you use the Action or Func to describe a method signature. Then, attach your concrete function - with matching parameter list - like a callback. Am I in the ballpark? Actions and Funcs are basically anonymous methods. An Action is an anonymous method that is void (i.e. returns nothing). A Func is an anonymous method that returns a value. In essence, it allows you to pass chunks of code around as method parameters. Dependency injection is a method of achieving inversion of control. It's also among the most common methods, so if you're familiar with dependency injection, you're pretty well set on IoC.
|
# ? Nov 9, 2020 20:05 |
|
|
# ? Jun 8, 2024 07:28 |
|
Dolemite you're going to do fine in .NET. You clearly show enough aptitude that any decently competent interviewer will let you reason yourself into the answer they want to hear (your thinking along Func/Action sold me). Now go learn that var is good and is not dynamic and you're golden.
|
# ? Nov 9, 2020 22:23 |
|
insta posted:var is good Oh, I see we are going to have to fight today... (I jest ofc, but I usually insist on avoiding var)
|
# ? Nov 9, 2020 23:34 |
|
Canine Blues Arooo posted:Oh, I see we are going to have to fight today... Hopefully we can all eventually come together to agree that whatever you decide to do, do it consistently.
|
# ? Nov 9, 2020 23:44 |
|
raminasi posted:Hopefully we can all eventually come together to agree that whatever you decide to do, do it consistently. Sure, do it consistently the way I like to do it.
|
# ? Nov 10, 2020 00:24 |
|
New Yorp New Yorp posted:Sure, do it consistently the way I like to do it. you goddamn right.
|
# ? Nov 10, 2020 00:39 |
|
Just curious - what are the objections to using var? I never used it until several months ago when I started adding Microsoft’s fxcop analyzer to my projects, and it definitely recommends using it. It saves some keystrokes when declaring say an ObservableDictionary<Foo, List<Bar>>
|
# ? Nov 10, 2020 01:20 |
|
My major beef with it is code readability / observing data flow, in addition to having a full understanding of how things work. For example, I just implemented language detection in a project with NTextCat. The code example provided looks like this: code:
We can easily identify factory as type RankedLanguageIdentifierFactory, but what the hell is identifier? Or languages...? We are calling FirstOrDefault on languages, so that's a clue, but it also doesn't narrow it down much. The point here is that if I were maintaining this code, understanding what I'm actually working with requires a bunch of extra time because I'm effectively eschewing one of the major advantages of a strongly typed language by not letting the reader know what these things actually are. Compare to: code:
This is also a fairly simple, self-contained example. The problem of readability and maintainability expands a lot as one expands the scope of a project.
|
# ? Nov 10, 2020 01:58 |
|
LongSack posted:Just curious - what are the objections to using var? I never used it until several months ago when I started adding Microsoft’s fxcop analyzer to my projects, and it definitely recommends using it. I've seen code examples where it is used for everything. Like: code:
|
# ? Nov 10, 2020 01:59 |
|
One of the objections I've heard even when the type is explicit on the right side of a declaration is that it can feel weird in some way for left-to-right readers. C# 9.0 adds target-typed new expressions, so pedants will have a new dimension of opinions to inflict on each other in a few days.code:
|
# ? Nov 10, 2020 02:11 |
|
Canine Blues Arooo posted:My major beef with it is code readability / observing data flow, in addition to having a full understanding of how things work. If you're using an IDE like VS, hovering over the variable will give you its type. I think Rider/R# has an option to show the type as a hint. var is better, if it leads to using longer/more descriptive variable names. I'd much rather see: code:
code:
|
# ? Nov 10, 2020 02:19 |
|
B-Nasty posted:If you're using an IDE like VS, hovering over the variable will give you its type. I think Rider/R# has an option to show the type as a hint. While I am personally a var-everywhere guy, I have to admit that it can easily become a pain in the rear end when you don't have an IDE right there, like during code reviews.
|
# ? Nov 10, 2020 02:21 |
|
a compromise i like is using var when the type of the rhs is clear (e.g. var foo = "bar"; var bar = 1m; var baz = new Dictionary<ValueTuple<int, long, long>, List<HashSet<string>[]>>()), and explicitly writing the type when it isn't
|
# ? Nov 10, 2020 02:26 |
|
raminasi posted:While I am personally a var-everywhere guy, I have to admit that it can easily become a pain in the rear end when you don't have an IDE right there, like during code reviews. Code Reviews are definitely a common use case where it gets obnoxious, but for complex structures, constantly having to mouse over stuff is a mental drain. Do you really want to have to mouse over stuff to see it's type, or would you rather it always be right there?
|
# ? Nov 10, 2020 02:27 |
|
I'm an always-var after being stymied at big refactors because of things like this:code:
code:
|
# ? Nov 10, 2020 03:03 |
|
Canine Blues Arooo posted:Code Reviews are definitely a common use case where it gets obnoxious, but for complex structures, constantly having to mouse over stuff is a mental drain. Do you really want to have to mouse over stuff to see it's type, or would you rather it always be right there? That would be the point of using descriptive variable names. If the variable (and function returning its value) are named well, I don't find the type adds much additional info. The example you had from NTextCat is a good example of bad variable names. Having a well-named variable continues to pay you back if the variable is used again and again. I'd rather not have to remember the type from when it was declared. I've found having the long type starts to eat too much into line length, and encourages a short, crappy variable name, thus reinforcing the problem.
|
# ? Nov 10, 2020 03:19 |
|
I don't disagree, but how you are going to descriptively name a Tuple<LanguageInfo, double> that implies it's type, or name something of an arbitrary type e.g. RankedLanguageIdentifier . I'd argue it's a 'both' kind of a thing, not one or the other.
|
# ? Nov 10, 2020 04:26 |
|
A decade or so ago, ReSharper insisted I slap var everywhere and it broke my brain.
|
# ? Nov 10, 2020 05:24 |
|
OK, I can see that. There’s a readability difference in var Foo = new ...() and var Foo = someObject.someMethod().
|
# ? Nov 10, 2020 05:27 |
|
I used to advocate for using var only in situations where it was obvious what type was being assigned based on the right hand side of the statement and/or a built in .Net method that was likely to be more stable over a given period of time. Now I just convert entire source files into a binary representation where whitespace indicates 0 and var indicates 1. Now my source code is
|
# ? Nov 10, 2020 05:31 |
|
Do people who advocate for var everywhere ever use Java? Because that's what not getting var gets you. I prefer using var in all cases where it's obvious -- i.e. var person = db.CreatePerson(); . Else you coed just looks.... gross.
|
# ? Nov 10, 2020 06:50 |
|
sorry your variable names and ide suck
|
# ? Nov 10, 2020 06:52 |
|
insta posted:I'm an always-var after being stymied at big refactors because of things like this: that should break though
|
# ? Nov 10, 2020 07:18 |
|
var is good and if the readability problem bothers you, you should know that the Roslyn team is adding a feature to VS to show the implicit types of things like var and lambda parameters, as well as method argument labels in some cases IIRC.redleader posted:that should break though I’m not sure I agree, changing the return type of a method is often done because of some arbitrary issue related to what specific container or whatever is needed, if the poo poo has all the things I want I am happy to be left alone and have the churn reduced. Another way to say this is: why is ‘var x = M1(); x.M2();’ not ok but ‘M1().M2()’ is totally fine
|
# ? Nov 10, 2020 08:56 |
|
redleader posted:that should break though Why? If you're not invoking any List-specific method or property, or if you're not passing it to a function that expects specifically a List, then your code shouldn't care. If you're only invoking .Count(), for example, then your local code was effectively fine taking in any IEnumerable (and if it had been turned into a named function, it would have taken an IEnumerable parameter). Canine Blues Arooo posted:Code Reviews are definitely a common use case where it gets obnoxious, but for complex structures, constantly having to mouse over stuff is a mental drain. Do you really want to have to mouse over stuff to see it's type, or would you rather it always be right there? This is why Visual Studio and VS Code show types as automatic CodeLens annotations in F# (where type inference is even more pervasive than 'var') : (the grey comments aren't real text, they're just IDE annotations) Obviously that's even more IDE reliance, and won't solve the code review problem (unless your IDE has a plugin for your VCS server that lets you do inline code reviews). Then again, C# is not exactly a Notepad-friendly language no matter how many QoL features you eschew. Canine Blues Arooo posted:I don't disagree, but how you are going to descriptively name a Tuple<LanguageInfo, double> that implies it's type, or name something of an arbitrary type e.g. RankedLanguageIdentifier . I'd argue it's a 'both' kind of a thing, not one or the other. Tuples should usually not be named at all, in recent versions of C# (or in F#) you can deconstruct them right there in the declaration: code:
code:
NihilCredo fucked around with this message at 11:33 on Nov 10, 2020 |
# ? Nov 10, 2020 11:14 |
|
redleader posted:that should break though Changing the return type of a function will propagate in unexpected ways if you overuse var. Usually this will cause compile errors that can be traced back to the var assignment, sometimes you'll be unlucky and the ramifications don't make themselves known until runtime. IMHO it's a loss of type safety. That said, I'll use var in a project that has the prefer-var lint rule, i just don't add that rule to my own projects.
|
# ? Nov 10, 2020 11:22 |
|
I only avoid var for primitive types like int, double and string. Using var for those looks wrong to me. Otherwise it's var all the time every time.Mata posted:
I haven't ever had this happen to me (specifically in relation to the use of var). But that might be because I haven't worked on the kind of project where that's a thing that can happen. Can you give an example?
|
# ? Nov 10, 2020 13:52 |
|
More WPF: I set up the list choices for the dialog box I'm working on and the text is getting cut off when I use it: [The Yes/No] I was being pretty bad about putting child elements inside the border tags, and I figured that would fix it, but it had no effect. Does anything else look obviously wrong? Here's a pastebin (50 lines) Regarding var: The most compelling justification I got for it was that most of the code doesn't have to care if something is a specific type or not so long as it has all the named things it's trying to do. So if you change foo.bar() in var x = foo.bar() to return something else, the code merrily hums along without having to change the types. You could subvert this argument by deciding to just use dynamic everywhere then. I wanted to post something cute here in spoilers where I just slapped dynamic on everything, but I think this would be the day one of you invented something that sends fists across the Internet and hit me with it. I tried to do a similar experiment using auto types for personal C++ work, but the tools had a much harder time telling me what stuff was when I was having a problem so it got frustrating. This was back in 2012 and I'd like to hope things have improved (please don't tell me the bad news).
|
# ? Nov 10, 2020 16:44 |
|
The difference is that dynamic actually sucks though
|
# ? Nov 10, 2020 16:47 |
|
You're right but it does take everything to its illogical conclusion!
|
# ? Nov 10, 2020 17:25 |
|
You should only be using dynamic in extremely specific situations; and foremost among those are some forms of COM interop, some forms of interop with objects given to you by a scripting engine, and some cases where you need to process arbitrarily-shaped JSON objects. And even in these cases there's often a better way you should be doing it instead. You should never be in a situation where you're looking at a var keyword and thinking "boy I should change that to dynamic", because var and dynamic fill entirely different purposes. Unless you can explain in detail why the actual contract of an object won't be known until runtime and why using adapter classes and interfaces isn't suitable, then dynamic is the wrong solution. At least, if your intention is to write performant, robust, and maintainable code, that is. If you're just making GBS threads out a quick utility that'll be used a few times and never seen again, then by all means go hog wild.
|
# ? Nov 10, 2020 17:31 |
|
If I'm remembering correctly, even with COM interop, you don't generally need to use dynamic if you use a PIA which you probably should if you can, so it's extremely rare to have a case where you need to use dynamic unless you're just messing around with COM objects using c# like a scripting language.
|
# ? Nov 10, 2020 17:47 |
|
I have also never seen the theoretical “var can cause incorrect type propagation during refactors that causes bugs” argument actually play out in practice. You’d need two different types with nominally matching contracts but different semantics. I can maybe imagine some problem with asymptotic complexity? Never run into one though. Re: dynamic: You can also use it to get multiple dispatch, if you ever happen to need that. I never have but it’s a spooky little corner of the language.
|
# ? Nov 10, 2020 19:43 |
|
I've run into the var + refactoring issue once, but it was long ago so I don't have a concrete example. It may have been async/await related?
|
# ? Nov 10, 2020 19:49 |
|
I've got a brain teaser here and I could use some extra ideas. I need to connect to an API run by a third party. To do that, I'm using this code:code:
I added the following lines right before the stream gets opened, because I'm just trawling StackOverflow and throwing in anything that's ever worked for anyone at this point: code:
|
# ? Nov 10, 2020 20:14 |
|
Rocko Bonaparte posted:More WPF: I set up the list choices for the dialog box I'm working on and the text is getting cut off when I use it: Your inner Grid (1*, 5*, 1* rows) has a certain amount of space that it can take up, based on the parent Grid (which is given 1/3 of the parent space based on the outer grid). The bottom row gets 1/7th (1* out of 7*) of the vertical space, which at the available space is not enough pixels to display the Yes/No choices at their given font size. Recommended solution: Use a Dockpanel for the inner grid, instead of a grid. Dockpanels are pretty great. They'll assign elements only as much space as they need, and then the last element in order gets all the remaining space. This means you can give the title and bottom choices list their required space, and then let the description fill the remainder. code:
|
# ? Nov 10, 2020 20:31 |
|
.NET 5 is out.
|
# ? Nov 10, 2020 20:31 |
|
CapnAndy posted:I've got a brain teaser here and I could use some extra ideas. A pretty detailed explanation can be found here: Transport Layer Security (TLS) best practices with the .NET Framework But a better way than trying various settings randomly is enabling System.Net network tracing. The logs aren't necessarily easy to read, but in there you should find mentions regarding which TLS versions it allows for connections on your side and also which ones are supported by the host... probably. It's been a while since I last did this, so I'm not 100% sure of the details, but in either case it should give you enough info to figure out what the actual problem is.
|
# ? Nov 10, 2020 21:39 |
|
mystes posted:.NET 5 is out. C# code:
C# code:
|
# ? Nov 10, 2020 21:43 |
|
|
# ? Jun 8, 2024 07:28 |
|
SirViver posted:I'm 99% sure this is a TLS issue.
|
# ? Nov 10, 2020 21:43 |