[deleted]
Programming Idioms
81–90 of 99 posts
Re: Programming Idioms
#82Earlier quoted context omitted.
Good news then, it’s also linear time like the marginally faster but enormously grotesque for loop provided previously. I would take that clarity of intent a hundred times over squeezing a couple of comparisons out.
> it’s also linear time You raise an interesting point. It got me thinking about how big-O notation has failed us in some ways: it teaches us to ignore constant factors. In big-O, an algorithm that makes 1000 comparisons per element is no different from one that makes a single comparison per element. They are both linear time. But you can't deny that one of these will likely take 1000 times as long as the other. Of c…
Sure, asymptotic time complexity only says anything about the asymptotic behavior. On the other hand, I have had far more cases of things blowing up due to cubic or even quadratic time complexities than I have for linear; linear is what you expect, if it takes a long time for a toy input, it'll take twice as long for a real input at double the size. Not so with the superlinear ones, your toy problem might work fine, but cubed? Ain't happening this millennium. This combined with the constant factor tending to also grow as the problem size grows really is a potent foot-gun.
Re: Programming Idioms
#83Earlier quoted context omitted.
The random idiom I got was: > Idiom #137 Check if string contains only digits > Set boolean b to true if string s contains only characters in range '0'..'9', false otherwise. char b = 0; for (int i = 0; i = '0' && s[i] I appreciate the funny assignment-and-test-and-early-break in one (although I'd hardly say it's idiomatic), but I could do without the quadratic strlen().
It's not unreasonable to assume the compiler will optimize it to a single call. Though I guess people who are capable of making that judgement won't need to look this idiom up on the internet.
It's still asking for trouble though. Look at this minor variation: https://godbolt.org/z/ncjEejsxe
It shows what happens if you take away the compilers' ability to reason about 's': it could be a global variable, and 'foo' could be modifying it, so now the compiler has to call strlen on every iteration.
So even though 'strlen' gets optimized out in the original version, it's quite a maintenance hazard since any minor change could inadvertently change the complexity from linear to quadratic. It also doesn't get optimized in debug builds, making those far slower than necessary.
Re: Programming Idioms
#84NSString *s=@(i).description;
is not how I would convert an integer to string in objective-c!
Re: Programming Idioms
#85Am 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.
And before C# got $-interpolation, almost every project had a static StringUtils class with an extension method FormatStr for string... seriously, I never quite understood the reasons why Format was made a static method instead of an instance method.
Re: Programming Idioms
#86Am 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.
The problem is people abuse of "var", and use it everywhere even when the type is not obvious from the right-hand expression/assignment. This is especially bad when reading code outside of an IDE, like in a GitHub PR, git/cli tools, etc...
From msdn/dotnet documentation:
> The use of var helps simplify your code, but its use should be restricted to cases where it is required, or when it makes your code easier to read.
https://docs.microsoft.com/en-us/dotnet/csharp/programming-g...
Also, C# 9.0 introduces target-typed new expressions:
https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...
Re: Programming Idioms
#87The random idiom I got was: > Idiom #120 Read integer from stdin > Read an integer value from the standard input into variable n int n[15]; fgets(n, 15, stdin); Really?
The random idiom I got was: > Idiom #137 Check if string contains only digits > Set boolean b to true if string s contains only characters in range '0'..'9', false otherwise. char b = 0; for (int i = 0; i = '0' && s[i] I appreciate the funny assignment-and-test-and-early-break in one (although I'd hardly say it's idiomatic), but I could do without the quadratic strlen().
Indeed!
I updated the implementation to hoist the quadratic strlen.
Re: Programming Idioms
#88I see a lot of people taking issue with the idioms presented, and rightfully so in many cases. Add the ability for people to improve or debate the solutions. Ultimately we should have a large curated cookbook (with additional variant selections and associated recipe variants). The most important human element of programming is knowing what to build (and what pieces to build to make the bigger thing). How often do I h…
It's already possible and encouraged to improve the solutions. The "edit" button shows up on computer browsers, not on mobile if the screen is small.
There's no "debate" capabilities, though.
Re: Programming Idioms
#89Earlier quoted context omitted.
We don't write code only for compilers, but for human readers as well. Why write code that makes a smart human wonder "Is that going to be quadratic? I'd better make sure the compiler optimizes it out!"
Smart human for you, someone obsessed with micro-optimization but lacking knowledge of compiler optimizations for me.. Writing it for human readers can be used to argue for the original implementation if you think of for(i=0;i<expr;i++) as the C idiom for "iterate expr times" and here you want expr to equal the length of the string, which is what the (obviously pure) function yields. No unnecessary variables and assi…
This conversation started when another developer was alarmed that the strlen() call in the for loop looked like it could be quadratic. I think we owe that dev the respect to not dismiss their concern as being "obsessed with micro-optimization but lacking knowledge of compiler optimizations".
I try to write code that is as plain and simple as possible, and make it obvious what it does and that it has no gotchas. I want my code to be understandable both for new developers, and for my future self, who will surely be less smart than I think I am today.
Here is the original code, with the loop body elided:
for( int i = 0; i for( int i = 0, n = strlen(s); i Of course, as I pointed out in another comment, if you're writing a loop that iterates over a C string, you never have to call strlen() at all! You can just use the canonical C string loop:
for( int i = 0; s[i] != '\0'; i++ ) {
}
for( int i = 0; s[i]; i++ ) {
}Re: Programming Idioms
#90Earlier quoted context omitted.
Smart human for you, someone obsessed with micro-optimization but lacking knowledge of compiler optimizations for me.. Writing it for human readers can be used to argue for the original implementation if you think of for(i=0;i<expr;i++) as the C idiom for "iterate expr times" and here you want expr to equal the length of the string, which is what the (obviously pure) function yields. No unnecessary variables and assi…
This conversation started when another developer was alarmed that the strlen() call in the for loop looked like it could be quadratic. I think we owe that dev the respect to not dismiss their concern as being "obsessed with micro-optimization but lacking knowledge of compiler optimizations". I try to write code that is as plain and simple as possible, and make it obvious what it does and that it has no gotchas. I wan…
[deleted]