问:
In plain English, what is recursion?
The idea of recursion is not very common in real world. So, it seems a bit confusing to the novice programmers. Though, I guess, they become used to the concept gradually. So, what can be a nice explanation for them to grasp the idea easily?</p>

答:
To explain recursion, I use a combination of different explanation, usually to both try to:

explain the concept,

explain why it matters,

explain how to get it.

For starters, Wolfram|Alpha defines it in more simple terms than Wikipedia:

An expression such that each term is generated by repeating a particular mathematical operation.

Maths

If your student (or the person you explain too, from now on I'll say student) has at least some mathematical background, they've obviously already encountered recursion by studying series and their notion of recursivity and their recurrence relation.

A very good way to start is then to demonstrate with a series and tell that it's quite simply what recursion is about:

a mathematical function...

... that calls itself to compute a value corresponding to an n-th element...

... and which defines some boundaries.

Usually, you either get a "huh huh, whatev'" at best because they still do not use it, or more likely just a very deep snore.

Coding Examples

For the rest, it's actually a detailed version of what I presented in the Addendum of my answer for the question you pointed to regarding pointers (bad pun).

At this stage, my students usually know how to print something to the screen. Assuming we are using C, they know how to print a single char using write or printf. They also know about control loops.

I usually resort to a few repetitive and simple programming problems until they get it:

the factorial operation,

an alphabet printer,

a reversed alphabet printer,

the exponentation operation.

Factorial

Factorial is a very simple math concept to understand, and the implementation is very close to its mathematical representation. However, they might not get it at first.

Alphabets

The alphabet version is interesting to teach them to think about the ordering of their recursive statements. Like with pointers, they will just throw lines randomly at you. The point is to bring them to the realization that a loop can be inverted by either modifying the conditions OR by just inverting the order of the statements in your function. That's where printing the alphabet helps, as it's something visual for them. Simply have them write a function that will print one character for each call, and calls itself recursively to write the next (or previous) one.

FP fans, skip the fact that printing stuff to the output stream is a side effect for now... Let's not get too annoying on the FP-front. (But if you use a language with list support, feel free to concatenate to a list at each iteration and just print the final result. But usually I start them with C, which is unfortunately not the best for this sort of problems and concepts).

Exponentiation

The exponentiation problem is slightly more difficult (at this stage of learning). Obviously the concept is exactly the same as for a factorial and there is no added complexity... except that you have multiple parameters. And that is usually enough to confuse people and throw them off at the beginning.

Its simple form:

can be expressed like this by recurrence:

Harder

Once these simple problems have been shown AND re-implemented in tutorials, you can give slightly more difficult (but very classic) exercises:

The Fibonacci numbers,

The Greatest Common Divisor,

The 8-Queens problem,

The Towers of Hanoi game,

And if you have a graphical environment (or can provide code stubs for it or for a terminal output or they can manage that already), things like:

Koch's Snow Flake Fractal,

Sierpinski's Triangle.

And for for practical examples, consider writing:

a tree traversal algorithm,

a simple mathematical expression parser,

a minesweeper game.

Note: Again, some of these really aren't any harder... They just approach the problem from exactly the same angle, or a slightly different one. But practice makes perfect.

Helpers

A Reference

Some reading never hurts. Well it will at first, and they'll feel even more lost. It's the sort of thing that grows on you and that sits in the back of your head until one day your realize that you finally get it. And then you think back of these stuff you read. The recursion,  recursion in Computer Science and recurrence relation pages on Wikipedia would do for now.

Level/Depth

Assuming your students do not have much coding experience, provide code stubs. After the first attempts, give them a printing function that can display the recursion level. Printing the numerical value of the level helps.

The Stack-as-Drawers Diagram

Indenting a printed result (or the level's output) helps as well, as it gives another visual representation of what your program is doing, opening and closing stack contexts like drawers, or folders in a file system explorer.

Recursive Acronyms

If your student is already a bit versed into computer culture, they might already use some projects/softwares with names using recursive acronyms. It's been a tradition going around for some time, especially in GNU projects. Some examples include:

Recursive:

GNU - "GNU's Not Unix"

Nagios - "Nagios Ain't Gonna Insist On Sainthood"

PHP - "PHP Hypertext Preprocessor" (and originall "Personal Home Page")

Wine - "Wine Is Not an Emulator"

Zile - "Zile Is Lossy Emacs"

Mutually Recursive:

HURD - "HIRD of Unix-Replacing Daemons" (where HIRD is "HURD of Interfaces representing Depth")

Have them try to come up with their own.

Similarly, there are many occurrences of recursive humor, like Google's recursive search correction. For more information on recursion, read this answer.

Pitfalls and Further Learning

Some issues that people usually struggle with and for which you need to know answers.

Why, oh God Why???

Why would you do that? A good but non-obvious reason is that it is often simpler to express a problem that way. A not-so-good but obvious reason is that it often takes less typing (don't make them feel soooo l33t for just using recursion though...).

Some problems are definitely easier to solve when using a recursive approach. Typically, any problem you can solve using a Divide and Conquer paradigm will fit a multi-branched recursion algorithm.

What's N again??

Why is my n or (whatever your variable's name) different every time? Beginners usually have a problem understanding what a variable and a parameter are, and how to things named n in your program can have different values. So now if this value is in the control loop or recursion, that's even worse! Be nice and do not use the same variable names everywhere, and make it clear that parameters are just variables.

End Conditions

How do I determine my end condition? That's easy, just have them say the steps out loud. For instance for the factorial start from 5, then 4, then ... until 0.

The Devil is in the Details

Do not talk to early abut things like tail call optimization. I know, I know, TCO is nice, but they don't care at first. Give them some time to wrap their heads around the process in a way that works for them. Feel free to shatter their world again later on, but give them a break.

Similarly, don't talk straight from the first lecture about the call stack and its memory consumption and ... well... the stack overflow. I often tutor students privately who show me lectures where they have 50 slides about everything there's to know about recursion when they can barely write a loop correctly at this stage. That's a good example of how a reference will help later but right now just confuses you deeply.

But please, in due time, make it clear that there are reasons to go the iterative or recursive route.

Mutual Recursion

We've seen that functions can be recursive, and even that they can have multiple call points (8-queens, Hanoi, Fibonacci or even an exploration algorithm for a minesweeper). But what about mutually recursive calls? Start with maths here as well. f(x) = g(x) + h(x) where g(x) = f(x) + l(x) and h and l just do stuff.

Starting with just mathematical series makes it easier to write and implement as the contract is clearly defined by the expressions. For instance, the Hofstadter Female and Male Sequences:

However in terms of code, it is to be noted that the implementation of a mutually recursive solution often leads to code duplication and should rather be streamlined into a single recursive form (See Peter Norvig's Solving Every Sudoku Puzzle.

Title: In plain English, what is recursion?


问:
Why are the  and  tags deprecated?
This question came up in one of my college classes. The professor only gave the answer that it was more descriptive, but it seems as though  and  are rather explicit in their meaning and is easier to type than  and .

What were the official arguments for the deprecation of these tags?

答:
The design principles underlying the HTML tags is that they should be "semantic" i.e. they should indicate meaning and intent rather than low level instruction.

The classic test is "can the tags be meaningfully used in a browser for the blind".

So for an audio based browser the "i" for italic is pretty useless as you cannot have italic speech. However the "em" tag is meaningful as an audio device can emphasize a phrase in many ways: by raising pitch, increasing volume or changing accent. A Braille renderer could emphasize by raising the dots changing spacing, changing size  or adding vibration.

ContentLicense: CC BY-SA 3.0

Title: Why are the <b> and <i> tags deprecated?


问:
Why aren't we building and using parallel processors *meant* for general computation?
We all know GPUs are much faster than CPUs for a wide range of applications. When someone asks why we are not just programming for GPUs at all, one of the most common answers is that GPUs are not good for everything - i.e., they fail to do some things that CPUs do easily. Well, no wonder: after all, they are not meant to be used for general computations. GPUs are strongly tied to games and graphical applications, not only having specialized functions for those, but often being advertised for them.

My question is: why, then, aren't we building and using processors that are actually designed for parallel programs?

答:
Parallel programming(multi-threaded) is hard. Orders of magnitudes harder then single-threaded programming.

Yes, you can get more performance, but this performance comes at a cost: developer time. And developer time is most often more costly then a program that's optimized a bit less but is finished sooner.


问:
What are the benefits of using entity framework code-first instead of designing my database using SQL?
I'm currently working on designing a small web application (MVC5) and I'm to the point of designing my database. I have the schema I want worked out and I am quite proficient in SQL Server. (I have my SQL 2012 MCSA.) I'm going to be using entity framework 6 as my ORM. I've been quite interested in the code-first approach because I'm not a big fan of designers and I like to be able to see and work with the code myself.

Because my SQL skills are quite strong I am inclined to create the schema myself and write my own CREATE TABLE queries, etc. I feel like that gives me a lot more control over constraint and index creation.

But I haven't really worked much with entity framework in the past so there may be some benefits to this that I'm missing. I know you can do code-first against an existing database in EF6 anyway, so that would be another option.

I've tried googling around a bit and reading MSDN but most of the benefits seems to be that you don't need to worry about the SQL. Since that isn't a concern of mine I'm failing to see the benefit of allowing entity framework to create my schema.

Are there any benefits to allowing entity framework to create my database that I'm missing?

答:
The biggest benefit in my opinion is that it allows you to focus on designing the model, not the database used to store it.

This makes things like separation of concerns etc. easier as your mental approach is already doing that by seeing entities as simple classes, not database tables.

Of course, you can always use Fluent API and data annotations to tweak the generated database scheme where needed, and once things settle down you can switch on migrations and use that to generate the comfort blanket that is SQL scripts (in a good way!) for deployment and schema management going forward.


问:
Is DDD not appropriate for my website or should I introduce a Query Layer?
I have inherited an ASP.NET website application and the previous developer has used what I believe are some DDD concepts. I am new to DDD and I have to admit I am struggling with the practical side of it having come from an N-Tier Transaction Script background.

One of the problems with the site is that it is slow. There is no paging on huge grids and also the business logic layer pulls down way more data than is needed for 90% of operations 70% of which are reads to bind data to grids.

The general design is that the business logic layer has a Service class per aggregate root, with various "GetByX()", 'FindBestMatching()" and "Update()" type methods on it. These Service classes are the points from which trees of domain objects are created such as "Organisation" and "User."

Back in my comfortable transaction script days, my service layer was similar: there would be some logic possibly, a call into a repository (or since EF 6 direct use of EF as it can be mocked for testing) and then the call would return. The objects that were returned would be DTO type objects containing return data relevant, including possibly some POCO entity objects. These DTOs would travel to clients via webservices, be bound to ASP.NET or Silverlight grids...all was good.

My operations on my service layer could be very specific, allowing for queries like:

```<code>"GetUsersWithSurnameIncludeChildren(string surname, int skip, int take)"
</code>```

allowing for nice narrow DB queries that supported paging and eager loading of related data. It was fast and loaded only the data that was actually needed.

Now with this site I have inherited there is an actual OO model of the business domain. These classes are POCOs, not generated from EF, but EF is used database first as a repository (there is a lot of mapping between the domain objects and the EF objects). An example domain object is below (without any logic).

```<code>public class Organisation
{
    public int OrganisationID { get; set; }
    public string Name { get; set; }

    public IList<Organisation> AssociatedOrganisations { get; set; }
    public IList<User> Staff { get; set; }
    public IList<User> Managers { get; set; }

    // Business logic method implemented below here
}
</code>```

Many of the classes are essentially copies of the underlying entity framework objects, others have a significant amount of logic encapsulated within them.

The way the site works currently is that every time the OrganisationService service class creates a new Organisation domain object (and it may create a collection in one hit) it also populates ALL of the fields and collections in that object...and all of the fields and collections in those objects! A huge deep tree is created in memory and a stack of joins and unions (generated by EF) is needed to get all of the data. This is totally inappropriate for a website that mainly displays loads of flat grids.

My questions are:

1) Is an application that is 70% pulling data out of a DB for display and 30% business logic actually a bad candidate for DDD?

2) If DDD is appropriate how are scenarios like this generally designed? Should I implement a separate "Query Service" that is designed just to pull out loads of flat data for binding to pages and grids (these could just be the EF POCOS themselves) and reserve the Domain objects just for parts of the application where logic must actually be performed?

3) Should I only load data into my Domain Object reference types and collections when it is actually accessed (like EF lazy loading...)? Previous posts I have read have suggested lazy loading in a Domain Object is a code smell: DDD Lazy Loading Code Smell

I am about to buy a DDD book tonight :)

答:
1) I wouldn't say that. DDD is good for complex systems (which may mean, anything more sophisticated than CRUD). Domain logic can be very complex regardless of its share in the system compared to query logic.

2) I see two ways of adressing this. One is limit aggregate size. Small aggregates are less prone to bloated, slow data loading. The other is separate your reads from your writes (CQRS). This is basically the "Query Service" you're mentioning, but it's better to have it return separate read model objects that are not your entities.

3) Calling entity lazy loading a code smell is somewhat... opinionated. It could actually be a solution. But you may still have performance problems with it, such as adding one entity to a huge collection forcing you to load this entire collection. A better aggregate design can address this.


问:
RefactorException: Good idea or bad idea?
When I'm doing large scale refactors I'm often commenting out the contents of methods and using NotImplementedExceptions for stuff that I still need to refactor. Problem is that this is interfering with 'valid' NotImplementedExceptions. I'm thinking about introducing a custom RefactorException, that I quite easily find back by reference to see what I still need to do.

Good idea or bad idea? What are other common ways to do large scale refactors in stages?

(of course the idea is that all these exceptions are removed before the I commit the whole refactoring)

答:
Refactoring is improving code in a way that doesn't affect it's functionality. That is, the public interface stays the same, but you might improve code formatting, algorithms, or implementation details. In a few cases, this might even be cleaning up a class hierarchy.

Because the behaviour of the code is the same before and after refactoring, you can use the same unit tests without change during refactoring. If you do not have tests, then writing tests for the part you are going to work on is the first step of refactoring:

Write unit tests for the unit you're working on.

Assert that the tests succeed with the current implementation.

Refactor.

Assert that the tests succeed with the new implementation.

You may have tests that don't test the externally visible behaviour, but test implementation details. Such tests make it easier to locate a problem, but they will have to be changed during step 3 “refactor”. The workflow is:

Design the refactoring. I.e. think about what you're going to change, and how it should work afterwards.

Rewrite the tests to test for the new implementation details.

Assert that the tests fail with the current implementation.

Refactor.

Assert that the tests succeed with the new implementation.

If you have tests for implementation details, it is crucial to clearly separate these from tests that test the public interface.

This workflow guarantees that during a refactoring step you will not forget a required piece of functionality.

How would you mark regions of code that require refactoring? I recommend using a comment as TODO: REFACTOR because explanation. Such comments could be added during a code review. You can easily grep for such a comment in a code base. You suggested editing in a throw new RefactorException() – but that means …

… you can't use the software until the refactoring is performed. Shipping working code now can be better than shipping beautiful code tomorrow.

… you can't run tests while those exceptions are in the code.

Test-driven refactoring will also lead you to the areas that need improvement, but contrary to your exceptions will give you the certainty that the code behaves the same before and after.


问:
Version controlling of a web project
We (2 developers) are developing a cakephp app that is running on a remote server. In NetBeans we both have project set up as "PHP application from remote server".
The problem is that whenever one of us modifies any of the files, they get instantly updated on the server, but not in the other developer's IDE. We have git + bitbucket set up, but that still looks somehow confusing

So I see two possible ways of doing it and please let me know if I am wrong.

First one:

1.) We keep on developing the project as "PHP application from remote server"
2.) Once one of us is done with his part, pushes it to the repo
3.) The other fetches, and pushes his commits for the other to fetch

But this way it is very confusing in the middle of a sprint, since the other develop had made changes to the script, and you see the system acting depending on those changes, but you cannot really see what exactly has been changed.

Second one:

1.) Develop separately on localhosts
2.) Push and fetch the changes
3.) Upload the project to the server

This way we loose the usage of server when developing. And it may bring a lot of trouble debugging once the changes are updated on the server

The questions are: are both of the views correct and we have to choose one, or do we skip/not know something that would help us in the proccess.

Any help, guidance or suggestions are much appreciated.

答:
You should definitely go with developing on localhosts (or your own separate vhosts on the server - to be sure you run the application under the same environment) and push-pull changes to the production environment only from VCS.

Otherwise why use a VCS at all? Just for the fun of it and as a redundancy for tour code? Version-control  systems are collaborative tools created with that specific goal in mind: collaboration. They have built-in conflict resolution and they make sure you don't override anyone else's work when you update a common (stage / test / production) environment.

As for the production server, you could write a small cronjob to do the pull in that machine every minute - as long as nobody uploads files directly (which would generate a conflict on pull after the file has been commited and pushed to the repo), then you're only pulling changes from the remote branch and everything should go smoothly with an automated process. But that's only if you want to really automate that - I recommend manual operations, and even that you would only do in a production environment when you are sure that you have a stable version. But for development & testing, separate virtual hosts on the same server should do the trick.

Title: Version controlling of a web project


问:
Recreating files from shell script or java?
I have java application which takes a file, which is created by a process running on terminal. I start the process using a small shell script. Then run the Java application and it reads the file created by the process.

Whenever this system runs created file need to be removed so that the process creates it using the same name. I have no control over the file creation process so I cant overwrite or append to the file.

My question is, on which part should the file be deleted? In the Java application or the little shell script i wrote?

I'm sorry if other aspects of the system seems poorly designed but as I said I have little control over it.

答:
I am big fan of stupid tools.  I want my hammer to hammer and my screwdrivers to screw.  If I use grep, I want to find something, but I don't want it to be able to e-mail me with the results.  If I wanted that, I could pipe it to some other tool that would do that.

Likewise, you have a Java program that can do anything imaginable.  Why exactly wouldn't it do anything imaginable?  It is because aside from losing time implementing something that isn't required of your program, the more functionality you add to a program, the more complicated it gets.  You're having to juggle the many different ways of calling the program, just to do the same thing that a tool already does, stupidly.

So in my humble opinion, you shouldn't be adding anything to the java program that can't be done in shell script.  Write a stupid program and let your shell script provide the logic behind it, which makes it easy to understand how it works as well as easy to change later.

If you find yourself doing these types of things often, you might want to consider looking into Ant, which is a multiplatform scripting language based on Java.


问:
Using the command pattern for a sequence of tasks
I have a 'sequence of tasks' to undertake on a zip file.  It can be simplified into these steps:

Validate that the file is a ZIP file and is valid

Unzip the file

Validate the contents are as expected

Turn the contents into a product

I am currently using the Command pattern and it looks a little something like this

```<code>interface Command {
    public function execute($data);
}

class ValidateFile implements Command {
    public function execute($filePath) { //... }
}

class UnzipFile implements Command {
    public function execute($filePath) { //... }
}

class ValidateContents implements Command {
    public function execute($unzippedFilePath) { //... }
}

class ProductGenerator implements Command {
    public function execute($unzippedFilePath) { //... }
}
</code>```

Now, each of these execute commands returns a string that is in turn (by the command invoker) passed to the next command in the chain (defined by configuration).

I am having two problems here:

Each command requires its own dependencies, i.e. unzip needs access to ZipArchive, a class that handles the unzipping of zip files. How do I inject each command's depenencies? I am quite happy to get around this by instantiating all of the commands through a DIC and plugging them into an 'Invoker' that accepts instantiated objects of type Command, the runs them in sequence, however it doesn't feel right.

(More of an issue) How do I persist more than a string between commands? I have seen in places people passing a 'context' object from one command to another, however this feels a bit dirty as the command would be depending upon an untyped interface (they essentially wrap an associative array).  It makes sense that it has to be untyped, as if you're to maintain an interface between commands, then the context can't implement any specific methods as that would deter from its abstraction.

I would appreciate any advice on how to deal with both of these issues.

Edit: Another issue I have is that each of these commands is actually coupled to the state of the file path that's passed to it, they're quite specific to the case at hand, but I doubt it's possible to work past that.

答:
To your first question: it is quite normal that each command constructor may have a different signature with different dependencies, so constructing the commands cannot be done fully generic. Using a DIC can indeed mitigate this.

For more complex scenarios, you could also use the "abstract factory" pattern, where you have one factory class per command, all of them derivated from an abstract factory interface, and each factory encapsulating the specific tasks for creating the individual command. These factories then can be passed to a generic "FactoryInvoker". But you should think twice if this is really worth the additional overhead in code.

To your second question: passing a 'context' object from one command to another is fine. Generic solutions sometimes come for the price of reducing some type safety. If you think you really need that much safety, make "context" an abstract base class, with different subclasses each one representing a different type of context. But beware, this can easily lead to a totally overengineered and unflexible solution, which may cause a lot of effort when you have to change the flow of commands afterwards.


答:
Adding the file deletion to the Java program has the drawback of making debugging hard, assumed the Java program does not behave as expected and you want to reproduce the behaviour with the original input data.

If the Java program is called from the shell script, it will make sense to add the deletion part to the script, since in this case the script knows when the Java program ends. But you wrote

I start the process using a small shell script. Then run the Java application and it reads the file created by the process.

This sounds you are starting the Java program manually. So the script does not know when the file was processed by your Java application, or when your Java application is terminated. So adding the file deletion to the script does not make sense either.

This leaves you with the following options:

delete the file manually after your Java application ends

write a second shell script starting your Java application and deleting the file afterwards (use this script to invoke your Java application)

don't delete the file after the Java application ends. Instead, remove the file (if it is there from a previous execution) by the shell script before it starts the file generating process.

In most cases, I would prefer the last alternative, since it will make the reproducing of any issues much easier.

Title: Recreating files from shell script or java?

Body:
I have java application which takes a file, which is created by a process running on terminal. I start the process using a small shell script. Then run the Java application and it reads the file created by the process.

Whenever this system runs created file need to be removed so that the process creates it using the same name. I have no control over the file creation process so I cant overwrite or append to the file.

My question is, on which part should the file be deleted? In the Java application or the little shell script i wrote?

I'm sorry if other aspects of the system seems poorly designed but as I said I have little control over it.


问:
Aggregation vs Composition
I understand what composition is in OOP, but I am not able to get a clear idea of what Aggregation is. Can someone explain?</p>

答:
How about this simple example:

An array of objects is a composition.
An array of pointers to objects is an aggregation.

If I delete the first one, its contents vanish with it.
The second one, on the other hand can vanish without affecting its members existence unless there is a specific method that deletes each object as its pointer is deleted.

Title: Aggregation vs Composition


问:
What is use of universal character names in identifiers in C++
The C++ standard (I noticed it in the new one, but it did already exist in C++03) specifies universal character names, written as \uNNNN and \UNNNNNNNN and representing the characters with unicode codepoints NNNN/NNNNNNNN. This is useful with string literals, especially since explicitly UTF-8, UTF-16 and UCS-4 string literals are also defined. However, the universal character literals are also allowed in identifiers. What is the motivation behind that?

The syntax is obviously totally unreadable, the identifiers may be mangled for the linker and it's not like there was any standard function to retrieve symbols by name anyway. So why would anybody actually use an identifier with universal character literals in it?

Edit: Since it actually existed in C++03 already, additional question would be whether you actually saw a code that used it?

答:
UPDATE - this answer, though it seemed to make sense to me and others, turns out to be largely wrong (and sufficiently wrong regarding the intent, as to be effectively just plain wrong). Since (as pointed out in a comment by AProgrammer) it's not permitted to use UCS outside of string constants when the same character could be represented normally in the base character set. So, no using it to escape keywords, as in my example; and no using it to make 'identifiers' like 23skiddo by escaping the 2. It could still be used to make names compatible with external languages, I guess, but only, it seems, when those names start with either a letter or an extended character, and contain only letters, digits, underline, and extended characters -- which seems much too restrictive to properly support that intent. So it must be that the main intent is (as in AProgrammer's answer) to allow these extra characters in identifiers, and to enable source editors where these characters are displayed graphically, while still allowing the source file to be in plain ASCII.

C++ programs may call functions written in other languages. It is good strategy on the part of the standardization committee to ensure that C++ will be interoperable with other languages which may allow non-alphanumerics or unicode characters in function names, even if such languages do not yet exist. The standard doesn't need to specify how this will work at the linker level, etc; but it's good to have a specified mechanism in place to allow it.

You don't need to look into the future to see a use for this. Suppose I have an old C library with a function in it called catch (or protected, or mutable)... and I want to call it from C++. And for whatever reason I can't or don't want to modify the C code (By the way, I have more than once had to deal with old C code that used a function name that had become a C++ keyword...)

With UC names I can write this in a header, and then just call 'catch_func()':

```<code>extern "C" {
       int catc\u0068( int a, int b );  // C 'catch()' function
}
inline int catch_func( int a, int b ) { return catc\u0068(a,b); }
</code>```

Sure it's ugly, but it doesn't matter since it's only in one place in the header. The same approach could be used to make stubs to call functions in other languages, and works even if the names are C++ keywords or unicode, or have spaces, . or other punctuation embedded in them

Various other languages have devices allowing the creation of identifiers that don't follow the general pattern; for instance in Verilog, \abcd is an identifier equivalent to abcd, but \while and \23skidoo and \44.e2 are identifiers too, which need the backslash prefix to be seen as such. Due to the manner in which Verilog is used, it's important to allow any names at all, where they relate to external interfaces.

Body:
UPDATE - this answer, though it seemed to make sense to me and others, turns out to be largely wrong (and sufficiently wrong regarding the intent, as to be effectively just plain wrong). Since (as pointed out in a comment by AProgrammer) it's not permitted to use UCS outside of string constants when the same character could be represented normally in the base character set. So, no using it to escape keywords, as in my example; and no using it to make 'identifiers' like 23skiddo by escaping the 2. It could still be used to make names compatible with external languages, I guess, but only, it seems, when those names start with either a letter or an extended character, and contain only letters, digits, underline, and extended characters -- which seems much too restrictive to properly support that intent. So it must be that the main intent is (as in AProgrammer's answer) to allow these extra characters in identifiers, and to enable source editors where these characters are displayed graphically, while still allowing the source file to be in plain ASCII.

C++ programs may call functions written in other languages. It is good strategy on the part of the standardization committee to ensure that C++ will be interoperable with other languages which may allow non-alphanumerics or unicode characters in function names, even if such languages do not yet exist. The standard doesn't need to specify how this will work at the linker level, etc; but it's good to have a specified mechanism in place to allow it.

You don't need to look into the future to see a use for this. Suppose I have an old C library with a function in it called catch (or protected, or mutable)... and I want to call it from C++. And for whatever reason I can't or don't want to modify the C code (By the way, I have more than once had to deal with old C code that used a function name that had become a C++ keyword...)

With UC names I can write this in a header, and then just call 'catch_func()':

extern "C" {
       int catc\u0068( int a, int b );  // C 'catch()' function
}
inline int catch_func( int a, int b ) { return catc\u0068(a,b); }

Sure it's ugly, but it doesn't matter since it's only in one place in the header. The same approach could be used to make stubs to call functions in other languages, and works even if the names are C++ keywords or unicode, or have spaces, . or other punctuation embedded in them

Various other languages have devices allowing the creation of identifiers that don't follow the general pattern; for instance in Verilog, \abcd is an identifier equivalent to abcd, but \while and \23skidoo and \44.e2 are identifiers too, which need the backslash prefix to be seen as such. Due to the manner in which Verilog is used, it's important to allow any names at all, where they relate to external interfaces.


问:
In Agile, should I create a code-review task?
My team uses Agile as a development approach. Currently, each task has four states which are todo, in progress, testing, and done.

We've just started doing code reviews, and I wonder if I need to create a code-review task or I should add time for code-review to the estimation?

答:
Before adding new states of any kind, I recommend considering what you'll use that state for. If there is some metric you're trying to track like cycle time in that state, then it might be beneficial. Otherwise, what's wrong with including code reviews in your definition of done?

I don't see the need to add additional complexity to your process just for the sake of having it. Is there value in having that state? What are you going to do with the information that knowing a thing is in that state gives you?


答:
It depends.

Personally, I like having tasks for code review work since it allows those things to be estimated properly. It also creates a tracking item that clearly shows if/when it gets done. And it lets you explicitly assign someone to do the code review, and keep that work balanced.

But I am also of the opinion that not all work needs code reviews, and certainly not always formal ones.

If your organization requires code reviews for everything, then it becomes a bit of boilerplate work to create all the tasks, and it represents a unit of work that is separate. If you're requiring it for everything, you don't want it separate - you want it ingrained as "something as natural as planning/coding/testing". So while I think that this approach to software development is overkill at most places, it is appropriate in others. In those cases, I would work to make code reviews a step in the process, not separate tasks.

Title: In Agile, should I create a code-review task?

Body:
My team uses Agile as a development approach. Currently, each task has four states which are todo, in progress, testing, and done.

We've just started doing code reviews, and I wonder if I need to create a code-review task or I should add time for code-review to the estimation?


问:
Is it a bad practice to use empty node with value attribute in XML?
I created XML parsing logic that forces XML to be formatted like this:

```<code><fooList>
    <fooObject value="SomeValue1" />
    <fooObject value="SomeValue2" />
</fooList>
</code>```

And then I started to think that a more elegant way would be

```<code><fooList>
    <fooObject>SomeValue1</fooObject>
    <fooObject>SomeValue2</fooObject>
</fooList>
</code>```

Are there any recommendations or good practices regarding this? I already know about Element vs. Attribute question, please note that mine is different.

答:
No, it is not bad practice.

In narrative text, it's a good idea to use text nodes for things the user will see (<title>Introduction</title>), and attributes for things the user won't see (
). In data-oriented XML, the decision is highly arbitrary, and neither way is right or wrong. Using elements is perhaps more extensible, since it allows you to introduce additional levels of structure in the future.

Body:
No, it is not bad practice.

In narrative text, it's a good idea to use text nodes for things the user will see (<title>Introduction</title>), and attributes for things the user won't see (<hr width="3pt"/>). In data-oriented XML, the decision is highly arbitrary, and neither way is right or wrong. Using elements is perhaps more extensible, since it allows you to introduce additional levels of structure in the future.


答:
If there's other xml data in the same system, try to use a consistent approach.

If there's not other xml data (or you're defining all of it), use whatever is easiest to use in your tool chain.

Title: Is it a bad practice to use empty node with value attribute in XML?

Body:
I created XML parsing logic that forces XML to be formatted like this:

```<code><fooList>
    <fooObject value="SomeValue1" />
    <fooObject value="SomeValue2" />
</fooList>
</code>```

And then I started to think that a more elegant way would be

```<code><fooList>
    <fooObject>SomeValue1</fooObject>
    <fooObject>SomeValue2</fooObject>
</fooList>
</code>```

Are there any recommendations or good practices regarding this? I already know about Element vs. Attribute question, please note that mine is different.


问:
How can a new programmer impress the software engineer (boss)?
I'm working at my first programming job. My boss is a very smart software engineer, and I feel
like I have very little to offer compared to him. Problem is, he is always busy, and needs someone to help him out. I feel like I'm not good enough, but I still want to succeed. I want to be a great programmer.

What can I do to impress him?

Thank you.

答:
Well, I just would add this quote from gospel:

"Whoever can be trusted with very little can also be trusted with much, and whoever is dishonest with very little will also be dishonest with much."

ContentLicense: CC BY-SA 2.5


问:
Boundary conditions for testing
Ok so in a programming test I was given the following question.

Question 1 (1 mark)

Spot the potential bug in this section of code:

```<code>void Class::Update( float dt )
{
    totalTime += dt;
    if( totalTime == 3.0f )
    {
        // Do state change
        m_State++;
    }
}
</code>```

The multiple choice answers for this question were.

a) It has a constant floating point number where it should have a named constant variable

b) It may not change state with only an equality test

c) You don't know what state you are changing to

d) The class is named poorly

I wrongly answered this with answer C.

I eventually received feedback on the answers and the feedback for this question was

Correct answer is a.  This is about understanding correct boundary conditions for tests.  The other answers are arguably valid points, but do not indicate a potential bug in the code.

My question here is, what does this have to do with boundary conditions? My understanding of boundary conditions is checking that a value is within a certain range, which isn't the case here. Upon looking over the question, in my opinion, B should be the correct answer when considering the accuracy issues of using floating point values.

答:
Everything about this question indicates that the teacher is not very good at his job.

bad language/grammar: the first 2 answers he refers to the program as it, in the 3rd answer the program is called you. To be more consistent and have better style it should have been at least: "You don't know what state it is changing to."

in the first answer the "constant floating point number" is confusing and should be "float literal", which is more precise and is much more commonly used to describe.. a literal :)

in the example a variable is called "m_State" where the convention is that the "m_" prefix indicates that the variable is a member variable. But then what is totalTime, it is not defined in the function, so it most probably is also a member variable and apparently not following the convention. Maybe its a global, but when the "m_" prefix is used, the "g_" prefix is also usually used to indicate a global variable. It could be a variable which is defined in that translation unit only (for example in the .cpp file where this function is defined), but that is just bad style. So yeah, whats up with this variable..

every answer is correct:

a) What does the literal 3.0f represent, it is indeed bad style to write code like that. The reader of the code has no idea why 3.0 is a 'boundary condition'. However it doesn't break the code.

b) When comparing floats for equality, a better way to do that is:

bool floats_are_equal(float a, float b)
{
    return std::abs(a - b) < std::numeric_limits<float>::epsilon()
}

And even this is frowned upon in some circles, they use a reinterpret_cast<T>() to convert the bit-representation the float to an (unsigned) int (with the same bit-representation in memory) and then you can do an exact comparison.
Also this is clearly the thing that is most wrong with this piece of code, because this most likely will cause the code to just not do what it is intended to do. All the other answers more have to do with style.

c) You don't know which state the program is switching to, that is correct. It tells you it is probably the next state, this could be enough depending on the context. I would rate this answer as least correct ;)

d) a class named Class is indeed very poorly named, obviously. And I think this is worse than using a literal. Though it is about on the same level.

In conclusion, this question does not convey any useful information about the person taking the test. In general multiple choice questions are not a good way to test if someone understands something. It is ok if you have to memorize facts. But in this case a free response would have been sooo much better.

Title: Boundary conditions for testing


问:
Null checking whilst navigating object hierarchies
I had to implement some code which traversed a small object hierarchy to fetch a value and display it in a TextView object (this is Android / Java). I had to do this 6 times to populate 6 TextViews for various values in the object hierarchy.

My implementation was Implementation B. But upon review, my colleague disagreed and certain that Implementation A was the way to go. I believe that my version is not just cleaner, but also less error prone as I could easily miss something as a developer.

Could you provide me with your opinion, with pros and cons for both of these implementations?

Implementation A:

```<code>if (house != null && house.getLounge() != null && house.getLounge().getLetter() != null)
{
    String myValue = house.getLounge().getLetter();
    textView.setText(myValue);
}
else
{
    // Do nothing, or maybe make textView hidden.
}
</code>```

Implementation B:

```<code>try
{
    String myValue = house.getLounge().getLetter();
    textView.setText(myValue);
}
catch (NullPointerException e)
{
    // Do nothing, or maybe make textView hidden.
}
</code>```

答:
Given the scenario you've given, I would go with implementation A.

In both implementations, the case where house is null or house.getLounge() or house.getLounge().getLetter() return null is handled.

One problem with implementation B is that it treats a NullPointerException that could happen in any of the methods called, which is an abnormal occurrence, as something normal. As commenters have pointed out, it "swallows" exceptions. It does not matter one bit if it can be demonstrated that the as of today, the methods called won't ever raise NullPointerException. Code changes, errors are introduced, what we thought was the case is in fact not the case, etc.

Implementation B also obscures the logic. When I look at implementation A, it is clear that the developer guarded against house being null, etc. I know what set of conditions will cause the "Do nothing..." branch to be taken. In implementation B what is the set of conditions that will result in a NullPointerException? Does getLounge sometimes raise a NullPointerException? I don't know without looking elsewhere.


问:
At what point should you start putting functions in a new file?
I'm currently writing a python script. It's currently about 400 lines long, and it seems like it's getting a bit long, as when I'm trying to scroll through it with eclipse it takes a bit to get from function A to function B. The structure is that it reads in a file, and then performs actions on what it reads in depending on the flags passed in by the user on the command line. Everything is more or less related (and in fact many functions call on other functions), so it makes sense in that regard to just leave everything in the same file.

I'm currently adding more features, or more things that can be put in for command line flags, and I'm wondering if there are any standards about how long a file should be before you start putting things into a new file. PEP 8 mentions the length of a line but nothing on the length of a file.

In summary: Are there any standards for how long a file should be before you just start throwing stuff into a new file?

答:
By splitting code across separate files you're creating modules. Modules help you break up your code and keep it maintainable and reusable. From the python documentation

If you quit from the Python interpreter and enter it again, the definitions you have made (functions and variables) are lost. Therefore, if you want to write a somewhat longer program, you are better off using a text editor to prepare the input for the interpreter and running it with that file as input instead. This is known as creating a script. As your program gets longer, you may want to split it into several files for easier maintenance. You may also want to use a handy function that you’ve written in several programs without copying its definition into each program.

To support this, Python has a way to put definitions in a file and use
them in a script or in an interactive instance of the interpreter.
Such a file is called a module; definitions from a module can be
imported into other modules or into the main module (the collection of
variables that you have access to in a script executed at the top
level...).

Try to keep interfaces between modules small so that you don't add unnecessary complexity to your program (you're trying to remove complexity by using modules). Also look at this Stack Overflow question

ContentLicense: CC BY-SA 4.0


答:
Version A is self-describing. It aims to do exactly what it says. Looking at version B taken out of context, I have no idea if the defense is supposed to be against house being null or textField being null (because, maybe, it's available on some layouts and unavailable on some other layouts - this would not be strange when dealing with android resources).

When one day textField is null because of some typo introduced to your layout file (which is quite probable in the long run - findViewById return null if it doesn't find ) - version A will make the error obvious and throw a helpful exception. And version B will hide the error, making an easy mistake a really obscure, well hidden bug.

The only thing to say for version "b" is that it's 53 characters shorter. Which is way to little to make it a good choice.

Title: Null checking whilst navigating object hierarchies

Body:
I had to implement some code which traversed a small object hierarchy to fetch a value and display it in a TextView object (this is Android / Java). I had to do this 6 times to populate 6 TextViews for various values in the object hierarchy.

My implementation was Implementation B. But upon review, my colleague disagreed and certain that Implementation A was the way to go. I believe that my version is not just cleaner, but also less error prone as I could easily miss something as a developer.

Could you provide me with your opinion, with pros and cons for both of these implementations?

Implementation A:

```<code>if (house != null && house.getLounge() != null && house.getLounge().getLetter() != null)
{
    String myValue = house.getLounge().getLetter();
    textView.setText(myValue);
}
else
{
    // Do nothing, or maybe make textView hidden.
}
</code>```

Implementation B:

```<code>try
{
    String myValue = house.getLounge().getLetter();
    textView.setText(myValue);
}
catch (NullPointerException e)
{
    // Do nothing, or maybe make textView hidden.
}
</code>```


问:
Intentionally incorrect use of language features, specifically "ref" in C#, as a hint to colleagues
I recently came across a piece of code something like this (roughly C#):

```<code>public bool ValidateStuff(ref ArrayList listOfErrors, Stuff thingsToValidate)
{
    if (!thingsToValidate.isValid() )
    {
        errors.add("New error!");
    }
}

ArrayList errors = [];
bool valid = ValidateStuff(ref errors, stuffToValidate);
</code>```

The key thing is the "ref" keyword - there is no need to use that keyword given the functionality here, and when I asked why it was there I was told that it had only been added as a kind of warning that the errors parameter is manipulated by the method, it's not purely used as input.

This immediately seemed wrong to me (ref has a purpose, and here it is not being used according to its purpose), but the idea of forcing (since you have to use ref when calling the method) a reminder of slightly counter-intuitive usage seemed reasonable, and I couldn't immediately think of a better way, apart from liberal use of comments.  What do you think?

Extra credit: how could this method be better? Perhaps by simply returning a new List of errors which is added to the main List in the calling code?  By providing two methods, one for the test and one for the errors?  Or is it fine as it is?

答:
Ugh. Always impressive when humanity shows how creatively terrible it can be...

Yes, the proper approach here is to return an IEnumerable of whatever your error type is (unless you're just using exceptions, in which case AggregateException exists). If you're doing anything remotely fancy with the errors, a special object that has a pass/fail property and is or exposes an IEnumerable of error type is the next step.


答:
I don't think you should break up the script just because of length. Any decent IDE should have the ability to collapse functions and/or skip to a specific function. There need to be good logical reason for seeing one part of it as functionally independent of the others. For example, if the function or functions for reading a file are generic enough, it might make sense to split them off into a separate module (file) which you then import. That way you can reuse that file reading module in a completely different program later, or make unit tests just for the file reading module, etc. Generally, I would say the following conditions should apply:

The module does has some logical separate subfunction that it is doing.

The module doesn't need to know anything about the script that is calling it (that isn't being passed as function parameters).

For example, the module should not check some global variable that is being set in the other script, or another module, or something like that.

Title: At what point should you start putting functions in a new file?

Body:
I'm currently writing a python script. It's currently about 400 lines long, and it seems like it's getting a bit long, as when I'm trying to scroll through it with eclipse it takes a bit to get from function A to function B. The structure is that it reads in a file, and then performs actions on what it reads in depending on the flags passed in by the user on the command line. Everything is more or less related (and in fact many functions call on other functions), so it makes sense in that regard to just leave everything in the same file.

I'm currently adding more features, or more things that can be put in for command line flags, and I'm wondering if there are any standards about how long a file should be before you start putting things into a new file. PEP 8 mentions the length of a line but nothing on the length of a file.

In summary: Are there any standards for how long a file should be before you just start throwing stuff into a new file?


答:
Understand that the ref keyword signifies an intent to reassign the pointer.

If you enable Microsoft's code analysis, you will get a warning telling you that using ref param is likely a bad design.

Passing by ref is not just a 'visual' or syntactic sugar change.  It actually allows the method to reassign the reference to a new object, which affects the calling code in ways that did not intend.

For example, without using ref, if the method tries to re-assign the paramter variable to a new object, it will NOT have any impact on the calling code's copy of the variable.

```<code>public bool ValidateStuff(ArrayList listOfErrors, Stuff thingsToValidate)
{
    if (!thingsToValidate.isValid() )
    {
        listOfErrors = new ArrayList(){"error"};
    }
}

ArrayList errors = ["existing error1", "existing error2"];
bool valid = ValidateStuff(errors, stuffToValidate);
Console.WriteLine(errors);  //output is still "existing error1", "existing error2"
</code>```

But the same thing using ref, actually changes the reference outside of the method:

```<code>public bool ValidateStuff(ref ArrayList listOfErrors, Stuff thingsToValidate)
{
    if (!thingsToValidate.isValid() )
    {
        listOfErrors = new ArrayList(){"error"};
    }
}

ArrayList errors = ["existing error1", "existing error2"];
bool valid = ValidateStuff(ref errors, stuffToValidate);
Console.WriteLine(errors);  //output is now "error"
</code>```

Now, in both of these pseudo code examples demonstrate a bug in the code.  The important difference is that, the first version is likely to cause a predictable error.  The second example could cause very unpredictable results in certain situations.

What to do instead

Now that you've (hopefully) accepted the fact that the language designers intended for ref to only be used when the method intends to reassign the pointer, you have only a few options:

Redesign your method to return the error list instead of being a void.

Add a new class containing everything that needs to be returned, and return a new instance of that class.

Pass multiple reference-type parameters (without using the ref keyword) and let the method modify them as necessary.

Beyond that, there's nothing else you can do.  The language was designed to be this way.  Don't drive yourself crazy over the fact that C# doesn't allow multiple return values.  I heard Go supports multiple return values if you can't accept it :D

Title: Intentionally incorrect use of language features, specifically "ref" in C#, as a hint to colleagues

Body:
I recently came across a piece of code something like this (roughly C#):

```<code>public bool ValidateStuff(ref ArrayList listOfErrors, Stuff thingsToValidate)
{
    if (!thingsToValidate.isValid() )
    {
        errors.add("New error!");
    }
}

ArrayList errors = [];
bool valid = ValidateStuff(ref errors, stuffToValidate);
</code>```

The key thing is the "ref" keyword - there is no need to use that keyword given the functionality here, and when I asked why it was there I was told that it had only been added as a kind of warning that the errors parameter is manipulated by the method, it's not purely used as input.

This immediately seemed wrong to me (ref has a purpose, and here it is not being used according to its purpose), but the idea of forcing (since you have to use ref when calling the method) a reminder of slightly counter-intuitive usage seemed reasonable, and I couldn't immediately think of a better way, apart from liberal use of comments.  What do you think?

Extra credit: how could this method be better? Perhaps by simply returning a new List of errors which is added to the main List in the calling code?  By providing two methods, one for the test and one for the errors?  Or is it fine as it is?

Body:
Understand that the ref keyword signifies an intent to reassign the pointer.

If you enable Microsoft's code analysis, you will get a warning telling you that using ref param is likely a bad design.

Passing by ref is not just a 'visual' or syntactic sugar change.  It actually allows the method to reassign the reference to a new object, which affects the calling code in ways that did not intend.

For example, without using ref, if the method tries to re-assign the paramter variable to a new object, it will NOT have any impact on the calling code's copy of the variable.

public bool ValidateStuff(ArrayList listOfErrors, Stuff thingsToValidate)
{
    if (!thingsToValidate.isValid() )
    {
        listOfErrors = new ArrayList(){"error"};
    }
}

ArrayList errors = ["existing error1", "existing error2"];
bool valid = ValidateStuff(errors, stuffToValidate);
Console.WriteLine(errors);  //output is still "existing error1", "existing error2"

But the same thing using ref, actually changes the reference outside of the method:

public bool ValidateStuff(ref ArrayList listOfErrors, Stuff thingsToValidate)
{
    if (!thingsToValidate.isValid() )
    {
        listOfErrors = new ArrayList(){"error"};
    }
}

ArrayList errors = ["existing error1", "existing error2"];
bool valid = ValidateStuff(ref errors, stuffToValidate);
Console.WriteLine(errors);  //output is now "error"

Now, in both of these pseudo code examples demonstrate a bug in the code.  The important difference is that, the first version is likely to cause a predictable error.  The second example could cause very unpredictable results in certain situations.

What to do instead

Now that you've (hopefully) accepted the fact that the language designers intended for ref to only be used when the method intends to reassign the pointer, you have only a few options:

Redesign your method to return the error list instead of being a void.

Add a new class containing everything that needs to be returned, and return a new instance of that class.

Pass multiple reference-type parameters (without using the ref keyword) and let the method modify them as necessary.

Beyond that, there's nothing else you can do.  The language was designed to be this way.  Don't drive yourself crazy over the fact that C# doesn't allow multiple return values.  I heard Go supports multiple return values if you can't accept it :D


问:
What is the right way to process inconsistent data files?
I'm working at a company that uses Excel files to store product data, specifically, test results from products before they are shipped out. There are a few thousand spreadsheets with anywhere from 50-100 relevant data points per file. Over the years, the schema for the spreadsheets has changed significantly, but not unidirectionally - in the sense that, changes often get reverted and then re-added in the space of a few dozen to few hundred files. My project is to convert about 8000 of these spreadsheets into a database that can be queried. I'm using MongoDB to deal with the inconsistency in the data, and Python.

My question is, what is the "right" or canonical way to deal with the huge variance in my source files? I've written a data structure which stores the data I want for the latest template, which will be the final template used going forward, but that only helps for a few hundred files historically. Brute-forcing a solution would mean writing similar data structures for each version/template - which means potentially writing hundreds of schemas with dozens of fields each. This seems very inefficient, especially when sometimes a change in the template is as little as moving a single line of data one row down or splitting what used to be one data field into two data fields.

A slightly more elegant solution I have in mind would be writing schemas for all the variants I can find for pre-defined groups in the source files, and then writing a function to match a particular series of files with a series of variants that matches that set of files. This is because, more often that not, most of the file will remain consistent over a long period, only marred by one or two errant sections, but inside the period, which section is inconsistent, is inconsistent.

For example, say a file has four sections with three data fields, which is represented by four Python dictionaries with three keys each.

For files 7000-7250, sections 1-3 will be consistent, but section 4 will be shifted one row down. For files 7251-7500, 1-3 are consistent, section 4 is one row down, but a section five appears. For files 7501-7635, sections 1 and 3 will be consistent, but section 2 will have five data fields instead of three, section five disappears, and section 4 is still shifted down one row. For files 7636-7800, section 1 is consistent, section 4 gets shifted back up, section 2 returns to three cells, but section 3 is removed entirely. Files 7800-8000 have everything in order.

The proposed function would take the file number and match it to a dictionary representing the data mappings for different variants of each section. For example, a section_four_variants dictionary might have two members, one for the shifted-down version, and one for the normal version, a section_two_variants might have three and five field members, etc. The script would then read the matchings, load the correct mapping, extract the data, and insert it into the database.

Is this an accepted/right way to go about solving this problem? Should I structure things differently? I don't know what to search Google for either to see what other solutions might be, though I believe the problem lies in the domain of ETL processing. I also have no formal CS training aside from what I've taught myself over the years. If this is not the right forum for this question, please tell me where to move it, if at all. Any help is most appreciated.

Thank you.

答:
Most IT "patterns" deal with repeatable, reproducible situations. Yours is exactly the opposite. You've got truly dirty data: Not just dirty instances, but changing, inconsistent, and occasionally erroneous schema, varying over time. Oy vey!

I don't know of a canonical, widely-accepted "best practice" name for dealing with such an irregular dataset, but cleaning up a largely- but incompletely-structured set of files is a common ETL problem. I call the pattern I use The Spice Must Flow. If you want to be very fancy, it's a variation on Management by Exception, augmented with agile/incremental development and an understanding of successive approximation.

Good News / Bad News

The bad news: By definition, you don't know exactly which parts of the files are good, how they're structured, whether the individual data elements are internally consistent, or where errors may crop up.

But, there's plenty of good news: People who collect data usually intend for it to be useful, even if they're somewhat haphazard when recording it. Large swaths of your files will be comprehensible. You didn't provide examples of the data, but from your description, you have maybe at most 12 different schema? And most of those seem to be variations, rather than wholly new or alien entities.

The Process

First create parsers/handlers for one (or a few) of the larger swaths of data that you can readily handle. When you encounter parts of the dataset you can't yet handle, write those parts to "remainders" or "leftovers" files for subsequent handling. Ideally this determination can be made mechanically, by the program. Occasionally, it's human judgment that dictates some sections are wrong/different/need special handling. In those cases, you will have to more explicitly direct that some files/parts of files be processed or directed to leftovers.

Next write a parser for one or two of the odd cases you couldn't manage earlier. Run those, processing the original leftovers, creating a second-generation leftovers file. Iterate this "write parser/handler, run, create leftovers" process until you have no further leftovers.

It's appealing to think that you could create enough parsers/handlers to deal with your entire dataset in one fell swoop. In my experience, that's rarely feasible or desirable. The process is fundamentally one of discovery. Unless your dataset is very small and regular, you probably have not observed/understood all the possible quirks, variations, and errors up-front. Even if you know a lot about them, you probably won't catch them all. Theory says there are an infinite number of possible variations; while the practical variations are fewer, they're often confounding. An agile/adaptive approach that assumes from the start that you don't know all the possible variations/errors is more realistic and less frustrating. It also encourages you to add many more checks and assertions into your handlers, which usually lead to further discoveries about the data formatting and structure, and bring to light other possible errors. Management by exception is all about handling the cases you can, with the lowest overhead and highest automation possible, setting aside the exceptions for further scrutiny and higher-touch fixes.

As you go through this process, you may decide to commit the data you have successfully parsed to your final dataset, then incrementally extend your "clean" dataset with the subsequent processing passes. Alternatively, you may decide to use the processing passes as primarily exploratory steps, then run the whole shebang from scratch once you've achieved zero-leftovers. The decision will be based on how much data you have, whether it's possible and/or valuable to use initial data even in an incomplete form, and whether any pass's discoveries have invalidated parsing/processing assumptions made on previous passes. If you have a very large amount of data (thousands of files is getting there), and it is independently sequenceable (i.e., does not need to processed from start to finish to make sense of it), a more incremental approach is good. If, however, the items are not easily processed out of order, or there are later discoveries that invalidate earlier runs, re-runs from scratch become more necessary.

It is often the case in such projects that one does not create official schema for all the variations seen. The N different schema and variations get encoded into the parsing/handling code that translates existing data files into the new, cleaned file/database. That may not be ideal, but the general idea is that you'll create one clean new dataset, and then have a better, cleaner, and genuine schema for new additions to the dataset.


问:
Do else blocks increase code complexity?
Here is a very simplified example. This isn't necessarily a language-specific question, and I ask that you ignore the many other ways the function can be written, and changes that can be made to it.. Color is of a unique type

```<code>string CanLeaveWithoutUmbrella()
{
    if(sky.Color.Equals(Color.Blue))
    {
        return "Yes you can";
    }
    else
    {
        return "No you can't";
    }
}
</code>```

A lot of people I've met, ReSharper, and this guy (whose comment reminded me I've been looking to ask this for a while) would recommend refactoring the code to remove the else block leaving this:

(I can't recall what the majority have said, I might not have asked this otherwise)

```<code>string CanLeaveWithoutUmbrella()
{
    if(sky.Color.Equals(Color.Blue))
    {
        return "Yes you can";
    }
    return "No you can't";
}
</code>```

Question: Is there an increase in complexity introduced by not including the else block?

I'm under the impression the else more directly states intent, by stating the fact that the code in both blocks is directly related.

Additionally I find that I can prevent subtle mistakes in logic, especially after modifications to code at a later date.

Take this variation of my simplified example (Ignoring the fact the or operator since this is a purposely simplified example):

```<code>bool CanLeaveWithoutUmbrella()
{
    if(sky.Color != Color.Blue)
    {
        return false;
    }
    return true;
}
</code>```

Someone can now add a new if block based on a condition after the first example without immediately correctly recognizing the first condition is placing a constraint on their own condition.

If an else block were present, whoever added the new condition would be forced to go move the contents of the else block (and if somehow they gloss over it heuristics will show the code is unreachable, which it does not in the case of one if constraining another).

Of course there are other ways the specific example should be defined anyways, all of which prevent that situation, but it's just an example.

The length of the example I gave may skew the visual aspect of this, so assume that space taken up to the brackets is relatively insignificant to the rest of the method.

I forgot to mention a case in which I agree with the omission of an else block, and is when using an if block to apply a constraint that must be logically satisfied for all following code, such as a null-check (or any other guards).

答:
In my view, the explicit else block is preferable. When I see this:

```<code>if (sky.Color != Blue) {
   ...
}  else {
   ...
}
</code>```

I know that I'm dealing with mutually exclusive options. I don't need to read whats inside the if blocks to be able to tell.

When I see this:

```<code>if (sky.Color != Blue) {
   ...
}
return false;
</code>```

It looks, on first glance, that it returns false regardless and has an optional side effect the sky isn't blue.

As I see it, the structure of the second code doesn't reflect what the code actually does. That's bad. Instead, choose the first option which reflects the logical structure. I don't want to have to check for return/break/continue logic in each block to know the logical flow.

Why anyone would prefer the other is a mystery to me, hopefully someone will take the opposite position will enlighten me with their answer.

I forgot to mention a case in which I agree with the omission of an
  else block, and is when using an if block to apply a constraint that
  must be logically satisfied for all following code, such as a
  null-check (or any other guards).

I'd say that guard conditions are okay in the case that you've left the happy path. An error or failure has occurred which prevents the ordinary execution from continuing. When this happens you should throw an exception, return an error code, or whatever is appropriate for your language.

Shortly after the original version of this answer, code like this was discovered in my project:

```<code>Foobar merge(Foobar left, Foobar right) {
   if(!left.isEmpty()) {
      if(!right.isEmpty()) {
          Foobar merged = // construct merged Foobar
          // missing return merged statement
      }
      return left;
   }
   return right;
}
</code>```

By not putting the return inside elses, the fact that a return statement was missing was overlooked. Had else's been employed, the code wouldn't even have compiled. (Of course, the far greater concern I have is that the tests written on this code were pretty bad not to detect this issue.)

Body:
In my view, the explicit else block is preferable. When I see this:

if (sky.Color != Blue) {
   ...
}  else {
   ...
}

I know that I'm dealing with mutually exclusive options. I don't need to read whats inside the if blocks to be able to tell.

When I see this:

if (sky.Color != Blue) {
   ...
}
return false;

It looks, on first glance, that it returns false regardless and has an optional side effect the sky isn't blue.

As I see it, the structure of the second code doesn't reflect what the code actually does. That's bad. Instead, choose the first option which reflects the logical structure. I don't want to have to check for return/break/continue logic in each block to know the logical flow.

Why anyone would prefer the other is a mystery to me, hopefully someone will take the opposite position will enlighten me with their answer.

I forgot to mention a case in which I agree with the omission of an
  else block, and is when using an if block to apply a constraint that
  must be logically satisfied for all following code, such as a
  null-check (or any other guards).

I'd say that guard conditions are okay in the case that you've left the happy path. An error or failure has occurred which prevents the ordinary execution from continuing. When this happens you should throw an exception, return an error code, or whatever is appropriate for your language.

Shortly after the original version of this answer, code like this was discovered in my project:

Foobar merge(Foobar left, Foobar right) {
   if(!left.isEmpty()) {
      if(!right.isEmpty()) {
          Foobar merged = // construct merged Foobar
          // missing return merged statement
      }
      return left;
   }
   return right;
}

By not putting the return inside elses, the fact that a return statement was missing was overlooked. Had else's been employed, the code wouldn't even have compiled. (Of course, the far greater concern I have is that the tests written on this code were pretty bad not to detect this issue.)


答:
In the specific example you gave, it does.

It forces a reviewer to read the code again to make sure it's not an error.

It adds (unnecessary) cyclomatic complexity because it adds one node to the flow graph.

I think it couldn't get any simpler that this:

```<code>bool CanLeaveWithoutUmbrella()
{
    return (sky.Color == Color.Blue);
}
</code>```

Title: Do else blocks increase code complexity?

Body:
Here is a very simplified example. This isn't necessarily a language-specific question, and I ask that you ignore the many other ways the function can be written, and changes that can be made to it.. Color is of a unique type

```<code>string CanLeaveWithoutUmbrella()
{
    if(sky.Color.Equals(Color.Blue))
    {
        return "Yes you can";
    }
    else
    {
        return "No you can't";
    }
}
</code>```

A lot of people I've met, ReSharper, and this guy (whose comment reminded me I've been looking to ask this for a while) would recommend refactoring the code to remove the else block leaving this:

(I can't recall what the majority have said, I might not have asked this otherwise)

```<code>string CanLeaveWithoutUmbrella()
{
    if(sky.Color.Equals(Color.Blue))
    {
        return "Yes you can";
    }
    return "No you can't";
}
</code>```

Question: Is there an increase in complexity introduced by not including the else block?

I'm under the impression the else more directly states intent, by stating the fact that the code in both blocks is directly related.

Additionally I find that I can prevent subtle mistakes in logic, especially after modifications to code at a later date.

Take this variation of my simplified example (Ignoring the fact the or operator since this is a purposely simplified example):

```<code>bool CanLeaveWithoutUmbrella()
{
    if(sky.Color != Color.Blue)
    {
        return false;
    }
    return true;
}
</code>```

Someone can now add a new if block based on a condition after the first example without immediately correctly recognizing the first condition is placing a constraint on their own condition.

If an else block were present, whoever added the new condition would be forced to go move the contents of the else block (and if somehow they gloss over it heuristics will show the code is unreachable, which it does not in the case of one if constraining another).

Of course there are other ways the specific example should be defined anyways, all of which prevent that situation, but it's just an example.

The length of the example I gave may skew the visual aspect of this, so assume that space taken up to the brackets is relatively insignificant to the rest of the method.

I forgot to mention a case in which I agree with the omission of an else block, and is when using an if block to apply a constraint that must be logically satisfied for all following code, such as a null-check (or any other guards).

Body:
In the specific example you gave, it does.

It forces a reviewer to read the code again to make sure it's not an error.

It adds (unnecessary) cyclomatic complexity because it adds one node to the flow graph.

I think it couldn't get any simpler that this:

bool CanLeaveWithoutUmbrella()
{
    return (sky.Color == Color.Blue);
}


答:
The principal reason for removing the else block that I have found is excess indenting. The short-circuiting of else blocks enables a much flatter code structure.

Many if statements are essentially guards. They're preventing the dereferencing of null pointers and other "don't do this!" errors. And they lead to a quick termination of the current function. For example:

```<code>if (obj === NULL) {
    return NULL;
}
// further processing that now can assume obj attributes are set
</code>```

Now it may seem that an else clause would be very reasonable here:

```<code>if (obj === NULL) {
    return NULL;
}
else if (obj.color != Blue) {
   // handle case that object is not blue
}
</code>```

And indeed, if that's all you're doing, it's not much more indented than the example above. But, this is seldom all you're doing with real, multi-level data structures (a condition that occurs all the time when processing common formats like JSON, HTML, and XML). So if you want to modify the text of all children of a given HTML node, say:

```<code>elements = tree.xpath(".//p");
if (elements === NULL) {
    return NULL;
}
p = elements[0]
if ((p.children === NULL) or (p.children.length == 0)) {
    return NULL;
}
for (c in p.children) {
    c.text = c.text.toUpperCase();
}
return p;
</code>```

The guards do not increase the indentation of the code. With an else clause, all of the actual work starts moving over to the right:

```<code>elements = tree.xpath(".//p");
if (elements === NULL) {
    return NULL;
}
else {
    p = elements[0]
    if ((p.children === NULL) or (p.children.length == 0)) {
        return NULL;
    }
    else {
        for (c in p.children) {
            c.text = c.text.toUpperCase();
        }
        return p;
    }
}
</code>```

This is starting to have significant rightward motion, and this is a pretty trivial example, with only two guard conditions. Every additional guard adds another indentation level. Real code I have written processing XML or consuming detailed JSON feeds can easily stack up 3, 4, or more guard conditions. If you always use the else, you end up indented 4, 5, or 6 levels in. Maybe more. And that definitely contributes to a sense of code complexity, and more time spent understanding what lines up with what. The quick, flat, early-exit style eliminates some of that "excess structure," and seems simpler.

Addendum Comments on this answer made me realize that it might not have been clear that NULL/empty handling is not the only reason for guard conditionals. Not nearly! While this simple example focuses on NULL/empty handling and doesn't contain other reasons, searching deep structures such as XML and ASTs for "relevant" content, for example, often has a long series of specific tests to weed out irrelevant nodes and uninteresting cases. A series of "if this node is not relevant, return" tests will cause the same kind of rightward drift that NULL/empty guards will. And in practice, subsequent relevance tests are frequently coupled with NULL/empty guards for the correspondingly deeper data structures searched--a double whammy for rightward drift.

Body:
The principal reason for removing the else block that I have found is excess indenting. The short-circuiting of else blocks enables a much flatter code structure.

Many if statements are essentially guards. They're preventing the dereferencing of null pointers and other "don't do this!" errors. And they lead to a quick termination of the current function. For example:

if (obj === NULL) {
    return NULL;
}
// further processing that now can assume obj attributes are set

Now it may seem that an else clause would be very reasonable here:

if (obj === NULL) {
    return NULL;
}
else if (obj.color != Blue) {
   // handle case that object is not blue
}

And indeed, if that's all you're doing, it's not much more indented than the example above. But, this is seldom all you're doing with real, multi-level data structures (a condition that occurs all the time when processing common formats like JSON, HTML, and XML). So if you want to modify the text of all children of a given HTML node, say:

elements = tree.xpath(".//p");
if (elements === NULL) {
    return NULL;
}
p = elements[0]
if ((p.children === NULL) or (p.children.length == 0)) {
    return NULL;
}
for (c in p.children) {
    c.text = c.text.toUpperCase();
}
return p;

The guards do not increase the indentation of the code. With an else clause, all of the actual work starts moving over to the right:

elements = tree.xpath(".//p");
if (elements === NULL) {
    return NULL;
}
else {
    p = elements[0]
    if ((p.children === NULL) or (p.children.length == 0)) {
        return NULL;
    }
    else {
        for (c in p.children) {
            c.text = c.text.toUpperCase();
        }
        return p;
    }
}

This is starting to have significant rightward motion, and this is a pretty trivial example, with only two guard conditions. Every additional guard adds another indentation level. Real code I have written processing XML or consuming detailed JSON feeds can easily stack up 3, 4, or more guard conditions. If you always use the else, you end up indented 4, 5, or 6 levels in. Maybe more. And that definitely contributes to a sense of code complexity, and more time spent understanding what lines up with what. The quick, flat, early-exit style eliminates some of that "excess structure," and seems simpler.

Addendum Comments on this answer made me realize that it might not have been clear that NULL/empty handling is not the only reason for guard conditionals. Not nearly! While this simple example focuses on NULL/empty handling and doesn't contain other reasons, searching deep structures such as XML and ASTs for "relevant" content, for example, often has a long series of specific tests to weed out irrelevant nodes and uninteresting cases. A series of "if this node is not relevant, return" tests will cause the same kind of rightward drift that NULL/empty guards will. And in practice, subsequent relevance tests are frequently coupled with NULL/empty guards for the correspondingly deeper data structures searched--a double whammy for rightward drift.


答:
The answer is a bit subjective. An else block can aid readability by establishing that one block of code executes exclusively to another block of code, without needing to read through both blocks. This can be helpful if, say, both the blocks are relatively long. There are cases, though where having ifs without elses can be more readable. Compare the following code with a number of if/else blocks:

```<code>if(a == b) {
    if(c <= d) {
        if(e != f) {
            a.doSomeStuff();
            c.makeSomeThingsWith(b);
            f.undo(d, e);
            return 9;
        } else {
            e++;
            return 3;
        }
    } else {
        return 1;
    }
} else {
    return 0;
}
</code>```

with:

```<code>if(a != b) {
    return 0;
}

if(c > d) {
    return 1;
}

if(e != f) {
    e++;
    return 3;
}

a.doSomeStuff();
c.makeSomeThingsWith(b);
f.undo(d, e);
return 9;
</code>```

The second block of code changes the nested if statements into guard clauses. This reduces indentation, and makes some of the return conditions clearer ("if a != b, then we return 0!")

It has been pointed out in the comments that there may be some holes in my example, so I will flesh it out a little more.

We could have written out the first block of code here like so to make it more readable:

```<code>if(a != b) {
    return 0;
} else if(c > d) {
    return 1;
} else if(e != f) {
    e++;
    return 3;
} else {
    a.doSomeStuff();
    c.makeSomeThingsWith(b);
    f.undo(d, e);
    return 9;
}
</code>```

This code is equivalent to both the blocks above, but it presents some challenges. The else clause here connects these if statements together. In the guard clause version above, the guard clauses are independent of each other. Adding a new one means simply writing a new if between the last if and the rest of the logic. Here, that can also be done, with only a slight amount more cognitive load. The difference, though, is when some additional logic needs to occur before that new guard clause. When the statements were independent, we could do:

```<code>...
if(e != f) {
    e++;
    return 3;
}

g.doSomeLogicWith(a);

if(!g.isGood()) {
    return 4;
}

a.doSomeStuff();
...
</code>```

With the connected if/else chain, this is not so easy to do. As a matter of fact, the easiest path to take would be to break up the chain to look more like the guard clause version.

But really, this makes sense. Using if/else weakly implies a relationship between parts. We could surmise that a != b is somehow related to c > d in the if/else chained version. That supposition would be misleading, as we can see from the guard clause version that they are, in fact, not related. That means that we can do more with independent clauses, like rearrange them (perhaps to optimize query performance or to improve logical flow). We can also cognitively ignore them once we are past them. In an if/else chain, I am less sure that the equivalence relationship between a and b won't pop back up later.

The relationship implied by else is also apparent in the deeply-nested example code, but in a different way. The else statements are separated from the conditional they are attached to, and they are related in reverse order to the conditionals (the first else is attached to the last if, the last else is attached to the first if). This creates a cognitive dissonance where we have to backtrack through the code, trying to line up indentation in our brains. It's a little like trying to match up a bunch of parenthesis. It gets even worse if the indentation is wrong. Optional braces don't help either.

I forgot to mention a case in which I agree with the omission of an else block, and is when using an if block to apply a constraint that must be logically satisfied for all following code, such as a null-check (or any other guards).

This is a nice concession, but it really doesn't invalidate any answer. I could say that in your code example:

```<code>bool CanLeaveWithoutUmbrella()
{
    if(sky.Color != Color.Blue)
    {
        return false;
    }
    return true;
}
</code>```

a valid interpretation for writing code like this could be that "we only must leave with an umbrella if the sky is not blue." Here there is a constraint that the sky must be blue for the code following to be valid to run. I've met the definition of your concession.

What if I say that if the sky color is black, it's a clear night, so no umbrella necessary. (There are simpler ways to write this, but there are simpler ways to write the whole example.)

```<code>bool CanLeaveWithoutUmbrella()
{
    if(sky.Color == Color.Blue)
    {
        return true;
    }

    if(sky.Color == Color.Black)
    {
        return true;
    }

    return false;
}
</code>```

As in the larger example above, I can simply add the new clause without much thought necessary. In an if/else, I can't be so sure I won't mess something up, especially if the logic is more complicated.

I will also point out that your simple example is not so simple, either. A test for a non-binary value is not the same as the inverse of that test with inverted results.

Body:
The answer is a bit subjective. An else block can aid readability by establishing that one block of code executes exclusively to another block of code, without needing to read through both blocks. This can be helpful if, say, both the blocks are relatively long. There are cases, though where having ifs without elses can be more readable. Compare the following code with a number of if/else blocks:

if(a == b) {
    if(c <= d) {
        if(e != f) {
            a.doSomeStuff();
            c.makeSomeThingsWith(b);
            f.undo(d, e);
            return 9;
        } else {
            e++;
            return 3;
        }
    } else {
        return 1;
    }
} else {
    return 0;
}

with:

if(a != b) {
    return 0;
}

if(c > d) {
    return 1;
}

if(e != f) {
    e++;
    return 3;
}

a.doSomeStuff();
c.makeSomeThingsWith(b);
f.undo(d, e);
return 9;

The second block of code changes the nested if statements into guard clauses. This reduces indentation, and makes some of the return conditions clearer ("if a != b, then we return 0!")

It has been pointed out in the comments that there may be some holes in my example, so I will flesh it out a little more.

We could have written out the first block of code here like so to make it more readable:

if(a != b) {
    return 0;
} else if(c > d) {
    return 1;
} else if(e != f) {
    e++;
    return 3;
} else {
    a.doSomeStuff();
    c.makeSomeThingsWith(b);
    f.undo(d, e);
    return 9;
}

This code is equivalent to both the blocks above, but it presents some challenges. The else clause here connects these if statements together. In the guard clause version above, the guard clauses are independent of each other. Adding a new one means simply writing a new if between the last if and the rest of the logic. Here, that can also be done, with only a slight amount more cognitive load. The difference, though, is when some additional logic needs to occur before that new guard clause. When the statements were independent, we could do:

...
if(e != f) {
    e++;
    return 3;
}

g.doSomeLogicWith(a);

if(!g.isGood()) {
    return 4;
}

a.doSomeStuff();
...

With the connected if/else chain, this is not so easy to do. As a matter of fact, the easiest path to take would be to break up the chain to look more like the guard clause version.

But really, this makes sense. Using if/else weakly implies a relationship between parts. We could surmise that a != b is somehow related to c > d in the if/else chained version. That supposition would be misleading, as we can see from the guard clause version that they are, in fact, not related. That means that we can do more with independent clauses, like rearrange them (perhaps to optimize query performance or to improve logical flow). We can also cognitively ignore them once we are past them. In an if/else chain, I am less sure that the equivalence relationship between a and b won't pop back up later.

The relationship implied by else is also apparent in the deeply-nested example code, but in a different way. The else statements are separated from the conditional they are attached to, and they are related in reverse order to the conditionals (the first else is attached to the last if, the last else is attached to the first if). This creates a cognitive dissonance where we have to backtrack through the code, trying to line up indentation in our brains. It's a little like trying to match up a bunch of parenthesis. It gets even worse if the indentation is wrong. Optional braces don't help either.

I forgot to mention a case in which I agree with the omission of an else block, and is when using an if block to apply a constraint that must be logically satisfied for all following code, such as a null-check (or any other guards).

This is a nice concession, but it really doesn't invalidate any answer. I could say that in your code example:

bool CanLeaveWithoutUmbrella()
{
    if(sky.Color != Color.Blue)
    {
        return false;
    }
    return true;
}

a valid interpretation for writing code like this could be that "we only must leave with an umbrella if the sky is not blue." Here there is a constraint that the sky must be blue for the code following to be valid to run. I've met the definition of your concession.

What if I say that if the sky color is black, it's a clear night, so no umbrella necessary. (There are simpler ways to write this, but there are simpler ways to write the whole example.)

bool CanLeaveWithoutUmbrella()
{
    if(sky.Color == Color.Blue)
    {
        return true;
    }

    if(sky.Color == Color.Black)
    {
        return true;
    }

    return false;
}

As in the larger example above, I can simply add the new clause without much thought necessary. In an if/else, I can't be so sure I won't mess something up, especially if the logic is more complicated.

I will also point out that your simple example is not so simple, either. A test for a non-binary value is not the same as the inverse of that test with inverted results.