Some of the examples don't do what the idiom says. Some aren't even close to good answers. Too many to rely upon this.
Yep! Curation is though.
Programming Idioms
91–99 of 99 posts
Re: Programming Idioms
#92No Swift? I like these projects. Fun
You may upvote the Swift request here: https://github.com/Deleplace/programming-idioms/issues/30
Re: Programming Idioms
#93Earlier quoted context omitted.
C# has evolved quite a bit over 20ish years. I suspect those posts predate $. Also: some people really oppose "var." I don't understand why, especially when newer languages like Swift and Rust really encourage similar idioms. Something something = new Something () is usually a smell to me. I personally find "var" much easier to work with.
These days `Something something = new();` is also allowed.
Why did they add this when we can already do:
var x = new Foo()
Re: Programming Idioms
#94Am I the only one bothered that many of these implementations of idioms are often not idiomatic according to the language? e.g. in C# the idiomatic way to instantiate something is typically to use the var keyword (unless the type of its value can't be inferred). And the idiomatic way to format a string is to use the $ special character, not string.Format... I suspect other languages
C# has evolved quite a bit over 20ish years. I suspect those posts predate $. Also: some people really oppose "var." I don't understand why, especially when newer languages like Swift and Rust really encourage similar idioms. Something something = new Something () is usually a smell to me. I personally find "var" much easier to work with.
Most of the time I met people opposing type inference those people thought 'var' would be dynamic typing. I truly don't understand why this misconception is still so widespread.
The argument that code becomes unreadable without an IDE is only true if identifiers aren't named properly (for example by heavy abuse of abbreviations, or even the usage of single-letter symbols).
The only places where type-inference should be avoided are "public interface" kind of things. It's best practice to be explicit about an "interface"—even in languages with full type inference. This avoids changing an interface unnoticed only by changing an expression somewhere. (I don't mean here C#'s Interfaces verbatim, but for example signatures of "package public" methods and such).
Re: Programming Idioms
#95Earlier quoted context omitted.
That is one of the most confusing pieces of C code I have seen lately. And it fails on an empty string: I would expect it to set b to 1 for an empty string, but it sets it to 0. Of course that could easily be fixed by setting b to 1 at the top. Also, code like this should always be put inside a function that returns a value, not just written inline. Making it a function allows simpler and more understandable code too…
You do realize it returns 1 for an empty string right? I mean it doesn't have any digits in it... What about adding a check of str[0] == 0 -> return 0 Also, giving char str[] will make it char* str. Which can be null. This may cause reading a random memory location (possibly segfault or use-after-free) edit: I get the comments but empty string still contains no digits. Given the regex would be ^[0-9]+ (+ instead of *…
Where did your choice of regex come from? The problem statement does not have any regex, and if you wanted to derive a regex from the problem statement you would probably need to get ^[0-9]*$ if you wanted to be correct.
Re: Programming Idioms
#96Earlier quoted context omitted.
These days `Something something = new();` is also allowed.
Why did they add this when we can already do: var x = new Foo() C# should have fewer, better considered features imo.
Maybe because people are still naming their identifiers "x" and such, and "new Foo()" could be some arbitrary expression?
Or maybe just because C# is a TIMTOWTDI language?
C# looks indeed quite baroque to me. But as I'm not doing any C# I don't know whether this is a good or a bad thing in practice.
OTOHS I guess less complexity in a language is generally to be preferred compared to having more flexibility doing the same thing.
Re: Programming Idioms
#97Earlier quoted context omitted.
These days `Something something = new();` is also allowed.
Why did they add this when we can already do: var x = new Foo() C# should have fewer, better considered features imo.
I think it can be useful for initialising properties and fields, where you are not allowed to use `var` (for good reason, if you ask me). But of all the recent features it's the one that I would miss least if it were taken away.
Re: Programming Idioms
#98Earlier quoted context omitted.
Why did they add this when we can already do: var x = new Foo() C# should have fewer, better considered features imo.
I think it can be useful for initialising properties and fields, where you are not allowed to use `var` (for good reason, if you ask me). But of all the recent features it's the one that I would miss least if it were taken away.
Fair point! Although I wish they had found a way to add F# style global inference rather all these little tricks
Re: Programming Idioms
#99Earlier quoted context omitted.
I think it can be useful for initialising properties and fields, where you are not allowed to use `var` (for good reason, if you ask me). But of all the recent features it's the one that I would miss least if it were taken away.
Fair point! Although I wish they had found a way to add F# style global inference rather all these little tricks
I suspect type inference becomes pretty tricky in the presence of subtyping.
I don't have any F# experience, but I have done some Haskell back in the days and I found the type inference very convenient. But I also think there is something to be said for limiting type inference to "inside" methods where it is effectively invisible to users of a class. Rust has made the same choice: you have type inference inside functions, but never outside.