coding-style

问题 I currently use soft tabs (i.e. spaces) for indenting my Ruby code, if I were to use hard tabs would it increase the performance when the code is interpreted? I assume it's faster to read one tab character than parse 4 space characters (however negligible). 回答1: Do you have an idea of all the phases involved in interpreting from source? Only the very first one, lexical analysis, has to deal with whitespace, and in the case of whitespace, "deal with" means "ignore it". This phase only takes a

问题 Closed . This question is opinion-based. It is not currently accepting answers. Want to improve this question? Update the question so it can be answered with facts and citations by editing this post. Closed 3 years ago . I have some code along the following pattern: return a().b().c().d().e(); now since every one of those methods could return null , one would usually test for this: if( (a()!=null) && (a().b() != null) && ....) { return a().b().c().d().e(); } else { return null; } (and maybe

问题 Looking at Type::Tiny, I see that the class name in the call to Type::Tiny->new is quoted in the official docs, my $NUM = "Type::Tiny"->new( name => "Number", constraint => sub { looks_like_number($_) }, message => sub { "$_ ain't a number" }, ); Why is this? Is this mere style? Is there any performance ramifications for this practice? 回答1: Take a simpler example package Foo { sub new { die 7 } }; package Bar { sub new { die 42 } }; sub Foo { "Bar" } Foo->new(); In the above example, the

问题 This question already has answers here : Closed 8 years ago . Possible Duplicate: What happens if I don't close a System.Diagnostics.Process in my C# console app? As System.Diagnostics.Process inherits from Component which implements IDisposable , should I always create a Process with a using block? For example, this...: using (var process = new Process()) { process.StartInfo.FileName = "some process.exe"; process.Start(); process.WaitForExit(); } ...instead of this: var process = new Process

问题 This question is only half tongue-in-cheek. I sometimes dream of a world without naked arrays or c strings. If you're using c++, shouldn't the preferred definition of main be something like: int main(std::vector<std::string> args) ? There are already multiple definitions of main to choose from, why isn't there a version that is in the spirit of C++? 回答1: A concern that keeps coming back to my mind is that once you allow complex types, you end up with the risk of exceptions being thrown in the

问题 I'm curious as to how often experienced Haskell programmers really use type inference in practice. I often see it praised as an advantage over the always-explicit declarations needed in certain other languages, but for some reason (perhaps just because I'm new) it "feels" right to write a type signature just about all the time... and I'm sure in some cases it really is required. Can some experienced Haskellers (Haskellites? Haskellizers?) provide some input? 回答1: It's still an advantage, even

问题 Where can I get the complete list of JSHint default options. I tried searching online but couldn't find anything. EDIT: I mean a list of default values for all options, in case it wasn't clear :) 回答1: You can look on boolOptions , valOptions and invertedOptions objects directly in jshint sources: https://github.com/jshint/jshint/blob/master/examples/.jshintrc If you are confused with comments, you can refer to options section in jshint help: http://jshint.com/docs/options/ 回答2: Actually, that

问题 After using a lot of Arel that Rails provides for sugar code, I am having problems when dealing with large and complex SQLs queries that I couldn't do it very well with Arel methods. I like Arel for little things, but when it get messy I prefer separate the code. So, is there any advice on how should I be treating my large SQLs inside models? Like, when should I create SQL Views for that (as I seen Rails do not provide very well, I have to create a migration for that) or create any separate

问题 I am a beginner in Rails. I use 2.3.X. I just saw Rails 3 is pre-released [ edit: now in release candidate! ]. I will most probably eventually switch to it. What are the common coding habits in 2.3 I should not take, so that the switch is as smooth as possible ? Edit: I've done my homework and read the Release notes. But they are far from clear for the most crucial points, for example : 1.5 New APIs Both the router and query interface have seen significant, breaking changes. There is a

问题 I am a beginner in Rails. I use 2.3.X. I just saw Rails 3 is pre-released [ edit: now in release candidate! ]. I will most probably eventually switch to it. What are the common coding habits in 2.3 I should not take, so that the switch is as smooth as possible ? Edit: I've done my homework and read the Release notes. But they are far from clear for the most crucial points, for example : 1.5 New APIs Both the router and query interface have seen significant, breaking changes. There is a