问:
Is it possible to create a single tokenizer to parse this?
This extends off this other Q&A thread, but is going into details that are out of scope from the original question.

I am generating a parser that is to parse a context-sensitive grammar which can take in the following subset of symbols:
,, [, ], {, }, m/[a-zA-Z_][a-zA-Z_0-9]*/, m/[0-9]+/

The grammar can take in the following string { abc[1] }, } and parse it as ({, abc[1], }, }).
Another example would be to take: { abc[1] [, } and parse it as ({, abc[1], [,, }).

This is similar to the grammar used in Perl for the qw() syntax.  The braces indicate that the contents are to be whitespace tokenized.  A closing brace must be on its own to indicate the end of the whitespace tokenized group.  Can this be done using a single lexer/tokenizer, or would it be necessary to have a separate tokenizer when parsing this group?

答:
As I understand it, lexers are non-discriminatory.  They break up tokens without context.  Thus the first example cannot be parsed using that tokenizer as the closing brace is not tightly bound to the comma.  The second example cannot be parsed that way, even if you tried to paste tokens together from within the parser (adding overhead and complexity), because there would not be a way to know when the first token ends and the next begins.

Both could be achieved if whitespaces were not ignored, but would add more complexity to the grammar/parser for all the other grammar rules.

So yes, it can be done.  But it depends on if the added overhead and complexity is worth it.


答:
Your grammar has ambiguities that make it impossible to know what to do with, say, the letter a without context.  In your case, the string abc can have two interpretations:  it can be an identifier (I'm assuming that's what your first m// defines), or it can be part of a string literal quoted in your { ... } notation (I'll call that a "quoted list").  Lexical analyzers (tokenizers) aren't smart enough to handle that kind of ambiguity, because their concept of context is very simplistic.  Parsers, on the other hand, can understand context at very deep levels.*

Language designers sometimes add sigils to their identifiers (e.g., $abc) to make them easier to tokenize.  This is why you can have a Perl variable named $for even though bare-naked for has special meaning.  For similar reasons, C lexers tokenize /"[^"]*"/ into a string literal because it has a context-independent syntax that doesn't appear anywhere else in the language.

Back to your problem:  Prematurely tokenizing a string of alphanumerics into an IDENTIFIER would mean the quoted list { abc[1]xyz } would be fed to the parser as { IDENTIFIER [ NUMBER ] IDENTIFIER }.  That's useful if those were the chunks in which you needed it, but you'd otherwise have to incorporate being able to handle combining all combinations of those tokens into the grammar for your quoted list.  Then you'd have to handle reassembling them back into string literals.  If you haven't guessed by now, that would get complex and ugly very quickly.  But because parsers understand context, putting that wisdom there makes it clean and easy.

For what you're doing, there shouldn't be much of a tokenizer at all because so much of it is context-sensitive, and that's all parser territory.  Whitespace doesn't seem to matter except in the context of a quoted list, so you could tokenize that as well as things that aren't ambiguous like LETTER and DIGIT.

```<code>// NOTE:  This code doesn't handle the case where whitespace is
// interspersed with the tokens.  See the comments.

quoted-list ::= '{' quoted-list-item-set '}'

quoted-list-item-set ::=
    <nothing>
    | string-of-non-whitespace-characters
    | string-of-non-whitespace-characters WHITESPACE quoted-list-item-set

// This ends up being things you have to put together and return,
// so that eventually you end up with a single string.
string-of-non-whitespace-characters ::=
    non-whitespace-character
    | non-whitespace-character string-of-non-whitespace-characters

non-whitespace-character ::= <anything in the set '!'..'~'>

identifier ::= LETTER alphanumeric-string

alphanumeric-string ::=
    <nothing>
    | alphanumeric alphanumeric-string

alphanumeric ::= LETTER | DIGIT

// ...etc...

// This prevents the parser from barfing on whitespace in any other context.
things-that-get-ignored ::= WHITESPACE
</code>```

*This is why you should use a parser to interpret something complex like XML and not fall into the trap of trying to understand it with regular expressions.

ContentLicense: CC BY-SA 3.0

Title: Is it possible to create a single tokenizer to parse this?

Body:
This extends off this other Q&A thread, but is going into details that are out of scope from the original question.

I am generating a parser that is to parse a context-sensitive grammar which can take in the following subset of symbols:
,, [, ], {, }, m/[a-zA-Z_][a-zA-Z_0-9]*/, m/[0-9]+/

The grammar can take in the following string { abc[1] }, } and parse it as ({, abc[1], }, }).
Another example would be to take: { abc[1] [, } and parse it as ({, abc[1], [,, }).

This is similar to the grammar used in Perl for the qw() syntax.  The braces indicate that the contents are to be whitespace tokenized.  A closing brace must be on its own to indicate the end of the whitespace tokenized group.  Can this be done using a single lexer/tokenizer, or would it be necessary to have a separate tokenizer when parsing this group?

Body:
Your grammar has ambiguities that make it impossible to know what to do with, say, the letter a without context.  In your case, the string abc can have two interpretations:  it can be an identifier (I'm assuming that's what your first m// defines), or it can be part of a string literal quoted in your { ... } notation (I'll call that a "quoted list").  Lexical analyzers (tokenizers) aren't smart enough to handle that kind of ambiguity, because their concept of context is very simplistic.  Parsers, on the other hand, can understand context at very deep levels.*

Language designers sometimes add sigils to their identifiers (e.g., $abc) to make them easier to tokenize.  This is why you can have a Perl variable named $for even though bare-naked for has special meaning.  For similar reasons, C lexers tokenize /"[^"]*"/ into a string literal because it has a context-independent syntax that doesn't appear anywhere else in the language.

Back to your problem:  Prematurely tokenizing a string of alphanumerics into an IDENTIFIER would mean the quoted list { abc[1]xyz } would be fed to the parser as { IDENTIFIER [ NUMBER ] IDENTIFIER }.  That's useful if those were the chunks in which you needed it, but you'd otherwise have to incorporate being able to handle combining all combinations of those tokens into the grammar for your quoted list.  Then you'd have to handle reassembling them back into string literals.  If you haven't guessed by now, that would get complex and ugly very quickly.  But because parsers understand context, putting that wisdom there makes it clean and easy.

For what you're doing, there shouldn't be much of a tokenizer at all because so much of it is context-sensitive, and that's all parser territory.  Whitespace doesn't seem to matter except in the context of a quoted list, so you could tokenize that as well as things that aren't ambiguous like LETTER and DIGIT.

// NOTE:  This code doesn't handle the case where whitespace is
// interspersed with the tokens.  See the comments.

quoted-list ::= '{' quoted-list-item-set '}'

quoted-list-item-set ::=
    <nothing>
    | string-of-non-whitespace-characters
    | string-of-non-whitespace-characters WHITESPACE quoted-list-item-set

// This ends up being things you have to put together and return,
// so that eventually you end up with a single string.
string-of-non-whitespace-characters ::=
    non-whitespace-character
    | non-whitespace-character string-of-non-whitespace-characters

non-whitespace-character ::= <anything in the set '!'..'~'>

identifier ::= LETTER alphanumeric-string

alphanumeric-string ::=
    <nothing>
    | alphanumeric alphanumeric-string

alphanumeric ::= LETTER | DIGIT

// ...etc...

// This prevents the parser from barfing on whitespace in any other context.
things-that-get-ignored ::= WHITESPACE

*This is why you should use a parser to interpret something complex like XML and not fall into the trap of trying to understand it with regular expressions.


问:
Returning a boolean when success or failure is the sole concern
I often find myself returning a boolean from a method, that's used in multiple locations, in order to contain all the logic around that method in a single place. All the (internal) calling method needs to know is whether the operation was successful, or not.

I'm using Python but the question isn't necessarily specific to that language. There are only two options I can think of

Raise an exception, though the circumstances are not exceptional, and remember to catch that exception in every place the function is called

Return a boolean as I'm doing.

This is a really simple example that demonstrates what I'm talking about.

```<code>import os

class DoSomething(object):

    def remove_file(self, filename):

        try:
            os.remove(filename)
        except OSError:
            return False

        return True

    def process_file(self, filename):

        do_something()

        if remove_file(filename):
            do_something_else()
</code>```

Although it's functional, I really dislike this manner of doing something, it "smells", and can sometimes result in a lot of nested ifs. But, I can't think of a simpler way.

I could turn to a more LBYL philosophy and use os.path.exists(filename) prior to attempting deletion but there's no guarantees the file won't have been locked in the meantime (it's unlikely but possible) and I still have to determine whether the deletion has been successful or not.

Is this an "acceptable" design and if not what would be a better way of designing this?

答:
A function is a contract, and its name should suggest what contract it will fulfil. IMHO, if you name it remove_file so it should remove the file and failing to do so should cause an exception. On the other hand, if you name it try_remove_file, it should "try" to remove and return boolean to tell if the file has been removed or not.

This would lead to another question -- should it be remove_file or try_remove_file? It depends on your call site. Actually, you can have both methods and use them in different scenario, but I think removing file per-se has high chance of success so I prefer having only remove_file that throw exception when fail.


问:
What is the name of a grammar which can change its tokenizer in mid parse?
I was creating a language and discovered that my language tokenizer would have to change depending where in the parse it is.

I.e. abc[1] would be parsed as 4 tokens (abc, [, 1, ]), where as { abc[1] } would be parsed as 3 ({, abc[1], }).

Is a grammar that would change its tokenizer mid parse defined somewhere? Does a grammar even define such a thing or is it irrelevant to the grammar and is just not really done on a parser level?

答:
Separate tokenizers are an implementation detail of parsers.  Separate tokenizers are not necessary; it is possible to create parsers without separate tokenizers.

However, separate tokenizers are often used in practice, and when they are, the tokens are often defined using (real) regular expressions.

If you're using a separate tokenizer, you may find it difficult or impossible to switch tokenizers in the middle of a parse.  However, there are no theoretical problems with doing this, just technological -- if you choose the right technology, it's actually quite easy to do.

So to answer your specific questions:

"Is a grammar that would change it's tokenizer mid parse defined somewhere?" This can happen with language composition.  Separate, regular tokenizers do not interact well with language composition.

"Does a grammar even define such a thing or is it irrelevant to the grammar and is just not really done on a parser level?"  Tokenization is a part of a grammar, so yes, a grammar is free to dictate how tokenization occurs depending on what rule it's trying to parse.  However, you may not see this often in practice.  Typically, at least in my experience, tokenization is regular and not context-free or context-sensitive.


答:
Yes, it's certainly possible to create a single tokenizer which can parse that.
I can easily create a <s>context-free</s> regular tokenizer which will correctly parse your language.

However, many popular tools may make it hard and/or impossible to tokenize your input the way you want, even if your tokenizer could be described by a regular grammar.  Using different tools, you may find it extremely easy to tokenize your input any way you want.

What approach you take to solve this problem may be largely dictated to you by your choice of tool.


问:
Best Practice for Argument Checking
Say I have a web service with a method MyWebServiceMethod(string passedValue).

The web service calls a method MyServiceMethod(string passedValue) where the value from the web service is passed along.

The service calls a repository method MyRepositoryMethod(string passedValue) where again, the value from the service is passed along.

I hope that is clear enough.  I can post code if need be.

My question is around null argument checking.

Should I check passedValue and throw an exception in:

The Web Service

The Service

The Repository

Obviously, if passedValue is null in the web service, the following methods will never get invoked but should I check in case the solution changes in the future?

Edit

I should have said that I don't expect null to ever be a valid value.

Also, My worry in these situations is that someone may change the web service or create another client with no argument checking that will call the service with invalid arguments.  So I tend to think the checking should be in both places.  Then I think of YAGNI and wonder if we should cross that bridge when we come to it.

What is considered best practice in these situations?

答:
If passedValue is used in either MyWebServiceMethod or MyServiceMethod in any way aside from calling MyServiceMethod and MyRepositoryMethod then you'll need to check it in those places so that whatever code in each of those layers that consumes passedValue has a valid value to work with.

If, on the other hand, at each layer passedValue is only used to call into the next layer, check it on the innermost layer and allow the exceptions to bubble up to the user from there.  That way you only have one place to maintain the code, should the expectations change.

Aside from that, don't worry too much about future consumers of any layer. If MyServiceMethod changes later to use passedValue in other work, the developer who adds that functionality should understand the implications of that change and protect themselves accordingly.

OwnerDisplayName: davy

Title: Best Practice for Argument Checking


问:
Is there any way to get faster at solving bugs? I've just had a warning from my boss
I've just been told by my boss that I will receive a negative performance review on Monday. He wants to talk to me about why I am so slow and why my bug fix rate is so low.

I love programming and solving problems but I actually do find my job really really hard.

I've actually been a programmer for about 10 years. But this is my first multithreading embedded linux job - I've been here 2 years and it's obvious to everyone that I'm still struggling. And I think I've become so demoralised and feel so marginalised that I've lost a lot of the fire that I had at the start of the job.

Has anyone ever been in a similar situation and how do you go about increasing your bug fix rate?

Update:
I had the review. I have been put on a 3 month 'employee development program' (of the type mentioned by Dunk ). Not sure whether I can turn this around. But even if I do have to move on, I've learned a lot from this experience.

Another Update

It's now about 6 weeks since the first review.
My advice to anyone facing the same situation is to be humble enough to take criticism and learn from your mistakes. And to not be afraid to look dumb. Ask loads and loads of questions. Let people know you're trying to learn and keep asking until you understand.
But be prepared for it not to work out. I'm constructing a portfolio of code ... as well as giving it my best shot.

Yet another update

I am hesitant to put this on here, since I'm concerned that I will not be able to refer future employers to my stackoverflow profile... But anyway, it might be of interest for someone reading this question, but I actually lost my job a few weeks ago. I'm in the midst of brushing up on all the skills I need to - I've taken a lot from the advice given here.

答:
Recognize that you work WITH employers and/or customer NOT for them. Do not hesitate to mention that in the interviews, just to set the record straight right from the start.

You are a professional with much invested in your small business, namely yourself.

You are willing to work while there is a Union of Interests propelling you out of the rack  each day.

If that propulsion is not there for a length of time, then move on.

You are wasting your time and energy on a bum employer that does not keep your interest going/skills updated/assignments challenging and/or interesting for you to work on. That is Management's job. Other than that they are pure overhead.....

Keep your passion going, as that is the key.


答:
In my opinion, it depends greatly on how the code is going to be used. If the code (classes, etc.) you are creating will be reused in multiple different ways -- or by other people -- then you might want to have multiple levels of checking (as appropriate -- it may be OK to just let a null reference exception happen). But if it's more likely to be kept to a small team (or yourself) then you can handle it wherever you want, and earlier may be better than later.

In my mind, it's the same kind of idea as whether you should do null checks. Some people say to do them anywhere something could possibly be null because this is "defensive programming." But if you control the code and know that null won't happen, then the checks are just a waste.

Title: Best Practice for Argument Checking

Body:
Say I have a web service with a method MyWebServiceMethod(string passedValue).

The web service calls a method MyServiceMethod(string passedValue) where the value from the web service is passed along.

The service calls a repository method MyRepositoryMethod(string passedValue) where again, the value from the service is passed along.

I hope that is clear enough.  I can post code if need be.

My question is around null argument checking.

Should I check passedValue and throw an exception in:

The Web Service

The Service

The Repository

Obviously, if passedValue is null in the web service, the following methods will never get invoked but should I check in case the solution changes in the future?

Edit

I should have said that I don't expect null to ever be a valid value.

Also, My worry in these situations is that someone may change the web service or create another client with no argument checking that will call the service with invalid arguments.  So I tend to think the checking should be in both places.  Then I think of YAGNI and wonder if we should cross that bridge when we come to it.

What is considered best practice in these situations?


答: Personally, it depends on what is going on in the methods. If the middle method is just passing it down, then I wouldn't check there. The method that needs to validate the parameter does the check. Even if the parameter is checked upstream, the method that needs a valid parameter should check.</p>

Title: Best Practice for Argument Checking


问:
Best github repository layout for snippets in multiple programming languages
I have to create a github-presence for an open-source organization. The aim is to distribute code snippets and reference implementations in different programming languages.

These contributions are going to be (ideally) created by people outside of the organization and should be collected.

I know that good practice is to create one repository per project. To this end, each implementation (in a specific programming language) should be considered a standalone project and should get its own repository. The point is that this approach makes hard for external people to contribute, because github pull-requests can only be made against existing repositories.

By creating a single repository with a subdirectory per programming language code contribution becomes easier, but I'm afraid that some IDEs may complain about the directory layout.

I'd like to know whether someone already solved this very specific problem in a satisfactory way.

答:
I haven't had this specific problem, but I have thought along these lines for a similar upcoming issue at my work.

As you say, a single repo has some nice advantages. Having each language as a directory in the root isn't a bad way to go if you need to keep them all together. Another option would be to create different branches for each language if you're worried about segregation (and possible IDE confusion).

But since you're working in github, you might want to take advantage of their organizational structure and create an organization/group with each language as a separate repo. New contributors adding a new language can just create their own github repo and then notify you to fork it.


问:
Is physical Agile board "always" better than electronic tool?
Whenever the question comes up on which Agile tool to use use there always some people that answer "don't use an electronic tool because you will lose the big-visible-board advantage which better generate team conversation".

Is this always the case or are there any contexts where an electronic tool is a better choice?  What are some of the pros and cons of each approach?

答:
An electronic agile board is a necessity for distributed teams.

For those of us where the entire team is in one room, the physical board is easier and more versatile, but lacks integration into other (electronic) systems.

There are teams in between, where not everyone is in the same room, but nearby. In this case a combination of both solutions might also make sense.

In general it depends on your demands whether you prefer one over the other or even both at the same time. The key point is that there is no such thing as the one solution for everyone. Try to achieve visibility, a place to talk about things, exchange ideas, a place to document things (and other demands the project poses) with your team and find out what board option or combination fits the demands best - that is your solution.


答:
Your intuition on this is correct, there is a better way to do this: monads.

What Are Monads?

Monads are (to paraphrase Wikipedia) a way of chaining operations together while hiding the chaining mechanism; in your case the chaining mechanism is the nested ifs. Hide that and your code will smell much nicer.

There are a couple of monads that will do just that ("Maybe" and "Either") and lucky for you they're part of a really nice python monad library!

What they can do for your code

Here's an example using the "Either" monad ("Failable" in the library linked to), where a function can return a Success or Failure, depending on what occurred:

```<code>import os

class DoSomething(object):

    def remove_file(self, filename):
        try:
            os.remove(filename)
            return Success(None)
        except OSError:
            return Failure("There was an OS Error.")

    @do(Failable)
    def process_file(self, filename):
        do_something()
        yield remove_file(filename)
        do_something_else()
        mreturn(Success("All ok."))
</code>```

Now, this might not look much different from what you have now, but consider how things would be if you had more operations that might result in a Failure:

```<code>    def action_that_might_fail_and_returns_something(self):
        # get some random value between 0 and 1 here
        if value < 0.5:
            return Success(value)
        else:
            return Failure("Bad value! Bad! Go to your room!")

    @do(Failable)
    def process_file(self, filename):
        do_something()
        yield remove_file(filename)
        yield action_that_might_fail(somearg)
        yield another_action_that_might_fail(someotherarg)
        some_val = yield action_that_might_fail_and_returns_something()
        yield something_that_used_the_return_value(some_val)
        do_something_else()
        mreturn(Success("All ok."))
</code>```

At each of the yields in the process_file function, if the function call returns a Failure then the process_file function would exit out, at that point, returning the Failure value from the failed function, instead of continuing on through the rest and returning the Success("All ok.")

Now, imagine doing the above with nested ifs! (How would you handle the return value!?)

Conclusion

Monads are nice :)

Notes:

I'm not a Python programmer -- I used the monad library linked to above in a script I ninja'd for some project automation. I gather, though, that in general the preferred, idiomatic approach is to use exceptions.

IIRC there's a typo in the lib script on the page linked to though I forget where it is ATM. I'll update if I remember. I diff'd my version against the page's and found: def failable_monad_examle(): -> def failable_monad_example(): -- the p in example was missing.

In order to get the result of a Failable decorated function (such as process_file) you have to capture the result in a variable and do a variable.value to get it.

Title: Returning a boolean when success or failure is the sole concern

Body:
I often find myself returning a boolean from a method, that's used in multiple locations, in order to contain all the logic around that method in a single place. All the (internal) calling method needs to know is whether the operation was successful, or not.

I'm using Python but the question isn't necessarily specific to that language. There are only two options I can think of

Raise an exception, though the circumstances are not exceptional, and remember to catch that exception in every place the function is called

Return a boolean as I'm doing.

This is a really simple example that demonstrates what I'm talking about.

```<code>import os

class DoSomething(object):

    def remove_file(self, filename):

        try:
            os.remove(filename)
        except OSError:
            return False

        return True

    def process_file(self, filename):

        do_something()

        if remove_file(filename):
            do_something_else()
</code>```

Although it's functional, I really dislike this manner of doing something, it "smells", and can sometimes result in a lot of nested ifs. But, I can't think of a simpler way.

I could turn to a more LBYL philosophy and use os.path.exists(filename) prior to attempting deletion but there's no guarantees the file won't have been locked in the meantime (it's unlikely but possible) and I still have to determine whether the deletion has been successful or not.

Is this an "acceptable" design and if not what would be a better way of designing this?

Body:
Your intuition on this is correct, there is a better way to do this: monads.

What Are Monads?

Monads are (to paraphrase Wikipedia) a way of chaining operations together while hiding the chaining mechanism; in your case the chaining mechanism is the nested ifs. Hide that and your code will smell much nicer.

There are a couple of monads that will do just that ("Maybe" and "Either") and lucky for you they're part of a really nice python monad library!

What they can do for your code

Here's an example using the "Either" monad ("Failable" in the library linked to), where a function can return a Success or Failure, depending on what occurred:

import os

class DoSomething(object):

    def remove_file(self, filename):
        try:
            os.remove(filename)
            return Success(None)
        except OSError:
            return Failure("There was an OS Error.")

    @do(Failable)
    def process_file(self, filename):
        do_something()
        yield remove_file(filename)
        do_something_else()
        mreturn(Success("All ok."))

Now, this might not look much different from what you have now, but consider how things would be if you had more operations that might result in a Failure:

    def action_that_might_fail_and_returns_something(self):
        # get some random value between 0 and 1 here
        if value < 0.5:
            return Success(value)
        else:
            return Failure("Bad value! Bad! Go to your room!")

    @do(Failable)
    def process_file(self, filename):
        do_something()
        yield remove_file(filename)
        yield action_that_might_fail(somearg)
        yield another_action_that_might_fail(someotherarg)
        some_val = yield action_that_might_fail_and_returns_something()
        yield something_that_used_the_return_value(some_val)
        do_something_else()
        mreturn(Success("All ok."))

At each of the yields in the process_file function, if the function call returns a Failure then the process_file function would exit out, at that point, returning the Failure value from the failed function, instead of continuing on through the rest and returning the Success("All ok.")

Now, imagine doing the above with nested ifs! (How would you handle the return value!?)

Conclusion

Monads are nice :)

Notes:

I'm not a Python programmer -- I used the monad library linked to above in a script I ninja'd for some project automation. I gather, though, that in general the preferred, idiomatic approach is to use exceptions.

IIRC there's a typo in the lib script on the page linked to though I forget where it is ATM. I'll update if I remember. I diff'd my version against the page's and found: def failable_monad_examle(): -> def failable_monad_example(): -- the p in example was missing.

In order to get the result of a Failable decorated function (such as process_file) you have to capture the result in a variable and do a variable.value to get it.


答:
Should I check passedValue and throw an exception in:

The Web Service

The Service

The Repository

What are you going to do if the string is null?  Throw an illegal argument exception to prevent a null pointer exception?

I would not check unless failure to do so could lead to a security hole.  A null pointer exception followed by a 404 or other error is a reasonable response to a user who types in an invalid URL for a web service call.  It is also a reasonable response when a web page constructs an incorrect URL.  A null pointer exception is a reasonable response to a developer who passes a null argument to a function that is not documented to accept a null.

There are many ways for an argument to be unusable.  An object reference can be null.  A floating point value can be infinite, or NaN.  An output stream may not be open.  Exceptions were invented to eliminate the need to check all these conditions at every level of the code.

Title: Best Practice for Argument Checking


问:
REST API internal directory structure and RewriteEngine
I'm building a REST API. I don't want to have real folders in my directory structure, but I'm not quite sure what to use else. My REST API uses paths like this:

```<code>api.server.com/<object>/<action>[/]
</code>```

Here, <object> is the object the action <action> should be performed on. For example, a URL api.server.com/user/create would create a new user.

For now, I've come up with this:

The objects all have their own file, like user.php for the object /user/. In the GET variable action a string determining the action is stored.

I'm using a .htaccess rewrite script to rewrite the fake directories to these internal paths:

```<code>RewriteEngine On
RewriteRule ^(.*?)/(.*?)/?$ $1.php?action=$2 [NC,L]
</code>```

However, I'm not sure if this is the best way of setting up a REST API. Would there be any obvious problems I'm missing here?

How does the internal file tree of a REST API usually look, or can't that be reasonably said? What are the pros and cons of different approaches?

答:
I think you are pretty much on the right track... It is hard to say if any particular way of structuring folders as "the best", but I can share what I have seen. In particular, the way ASP.NET MVC structures this sort of thing is as follows:

Models

Views

Controllers

{Miscellaneous other folders}

Models Contains the classes that represent your view models, or in the case of an API project, the data types that your API sends and receives; eg Person { Name, Rank, SerialNumber }.

Views Contains the files which generate your views; for an API project you don't really have views, you would just use some sort of JSON or XML serialization layer, so you probably don't need something like this.

Controllers Contains the classes that have your actions on them. This is pretty much what you are talking about doing, but it is worth nothing the separation between the data class (ie the Person object, with { Name, Rank, SerialNumber }) and the Person controller, which supports GET, PUT, POST, DELETE of a Person object.

Miscellaneous other folders would contain any other resources you need; also not all that necessary for a purely API project.


答:
First, a confidence boost:

Why suffer? You can easily find a job where they will think you're "god" just because you can do Linux embedded anything, regardless of your bug fix rate.

Anyway, it's impossible to set a time limit on hunting a bug. Bug hunting is a skill, no doubt, and efficiency in it is highly valuable.

You might be missing some basic trick that others know about, which makes you slower.

For instance, if you and I are working on some Linux middleware, and I'm using Valgrind to find memory corruption problems and data race conditions, whereas you're only relying on gdb and printf, I will probably kick your butt, even if you're smarter than me.

Also, how is your understanding of concurrency? If you've been developing for ten years, but most of that experience wasn't with multithreaded code, that could be a problem.

You should study multithreading in detail: more than just knowing how to use the API's, but really "get" it on a deep level. If you're doing multithreaded programming, you should be that developer who can look at a codebase from a mile away and spot scenarios of race conditions, deadlocks, priority inversions, starvation ...

Title: Is there any way to get faster at solving bugs? I've just had a warning from my boss

Body:
I've just been told by my boss that I will receive a negative performance review on Monday. He wants to talk to me about why I am so slow and why my bug fix rate is so low.

I love programming and solving problems but I actually do find my job really really hard.

I've actually been a programmer for about 10 years. But this is my first multithreading embedded linux job - I've been here 2 years and it's obvious to everyone that I'm still struggling. And I think I've become so demoralised and feel so marginalised that I've lost a lot of the fire that I had at the start of the job.

Has anyone ever been in a similar situation and how do you go about increasing your bug fix rate?

Update:
I had the review. I have been put on a 3 month 'employee development program' (of the type mentioned by Dunk ). Not sure whether I can turn this around. But even if I do have to move on, I've learned a lot from this experience.

Another Update

It's now about 6 weeks since the first review.
My advice to anyone facing the same situation is to be humble enough to take criticism and learn from your mistakes. And to not be afraid to look dumb. Ask loads and loads of questions. Let people know you're trying to learn and keep asking until you understand.
But be prepared for it not to work out. I'm constructing a portfolio of code ... as well as giving it my best shot.

Yet another update

I am hesitant to put this on here, since I'm concerned that I will not be able to refer future employers to my stackoverflow profile... But anyway, it might be of interest for someone reading this question, but I actually lost my job a few weeks ago. I'm in the midst of brushing up on all the skills I need to - I've taken a lot from the advice given here.


问:
How do you dive into large code bases?
What tools and techniques do you use for exploring and learning an unknown code base?

I am thinking of tools like grep, ctags, unit-tests, functional test, class-diagram generators, call graphs, code metrics like sloccount, and so on. I'd be interested in your experiences, the helpers you used or wrote yourself and the size of the code base with which you worked.

I realize that becoming acquainted with a code base is a process that happens over time, and familiarity can mean anything from "I'm able to summarize the code" to "I can refactor and shrink it to 30% of the size". But how to even begin?

答:
There won't be any documentation or there will be scant documentation, or it will be out of date. Find all the documentation that does exist. If it's in a team repository, don't make a copy. If not, put it there and ask your manager for permission to organize it, perhaps with some supervision.

Get everything up into the repository for the team and add a Glossary. All bases have jargon; document it in the glossary. Make sections for tools, products, customer-specific, etc.

Create / Update a software environment creation document. All tools, quirks, install choices, etc. go here.

Then upload a Getting Started With "ProductName" document or the like. Let it be just mind flow and self-organize over time. Then go through out of date docs and get them back to date. The other developers will appreciate it, you'll be contributing in a unique way whilst learning the code. Especially document all such things that stump you or are named wrong or are counter-intuitive.

Once your leaning curve is coming to an end, don't worry about updating the documentation. Let the next new guy do that. When he arrives, point him to your work. When he continually bugs you for answers, don't answer him. Rather, add the question to your documentation and then hand him the url. Fishing pole.

One side-effect is that you will have made a tool you yourself can reference months from now when you forget.

And although it's not documentation, a related issue is all the little quirky, manually intensive procedures your team mates do. Automate them with batches, sql scripts and the like, and share those as well. After all, procedural knowledge is arguably as big as declarative knowledge in terms of getting productive in a new environment. Whatever it is, don't do it; rather, script it, and run the script. Fishing pole strikes again.

Title: How do you dive into large code bases?


答:
In this particular case it may be useful to think about why you may not be able to remove the file. Let's say the problem is that the file may or may not exist. Then you should have a function doesFileExist() that returns true or false, and a function removeFile() that just deletes the file.

In your code you would first check if the file exists. If it does, call removeFile.  If not, then do other stuff.

In this case you may still want removeFile to throw an exception if the file cannot be removed for some other reason, such as permissions.

To summarize, exceptions should be thrown for things that are, well, exceptional. So if it is perfectly normal that the file you are trying to delete may not exist, then that is not an exception. Write a boolean predicate to check for that. On the other hand, if you do not have the write permissions for the file, or if it is on a remote file system that is suddenly inaccessible, those may very well be exceptional conditions.


答:
Many answers have questioned your boss' methods/tactics/metrics/etc. But that is beside the point. Maybe you ARE slow. Every room of developpers has to have ONE that's slower than the rest, right? (That's just straight set-theory.) So let's assume that's you. The answer is, WHY are you slow? (Clearly that is the question you have to answer before you can solve your stated question of how to get faster.)

There could be all sorts of reasons, but here are some possible explanations to consider:

You are less intelligent than they are. It's possible, right? (Studies have shown that we ALL are less-popular, less-interesting, and (it would follow) less intelligent than our friends.) So maybe you are just slow-brained. Then again, in your case I think this is unlikely. A quick glance of your StackOverflow profile shows that you have a history of asking intelligent questions on a wide range of topics. So you're obviously a thinker and probably a good one at that.

You're spread too thin. That same SO profile of yours shows that your questions cover a very wide gamut of technologies over these past 2 years (graphics, web, python, c++, c, linux, embedded, threads, sockets etc). Personally, I know that when I have been put in the situation of having (or wanting) to delve into a multitude of different streams, I find myself swimming up-current really fast (or, rather, really slow). Perhaps what you really need here is FOCUS. And maybe a healthy dose of prioritization. Is there anyway you can relegate the less-important pots to the back burner and turn up the heat on the main dish?

You're not having fun. When the fire dies down, the steam engine is destined to decelerate. You admitted in your post that your morale has taken a severe hit lately. Unfortunately you've been swallowed into the sucking vortex of self-reinforcing negative harmonics -- a force that can destroy bridges. It's an all-too-familiar spiral: difficult task -> stress -> missed deadline -> more stress -> poor coping mechanism -> more stress -> procrastination -> more missed deadlines -> criticism/gossip (real or imagined) -> yet more stress. You get the picture. This rarely leads anywhere useful. Take a lesson from my days in white-water rafting: When you get sucked under-water by a circulating current on the back-side of a class-4 rapid, your life-jacket will NOT buoy you back to the surface. The best strategy (though non-intuitive) is to find the bottom of the river, and walk out of the riptide. So my advice to you is: find some ground, dude, (friends, church, healthy new habits, etc) and make use of it to ambulate yourself out of the whirlpool.

You're not in your zone. Michael Jordan made a pretty lame baseball player. (OK, he was still better than me, but definitely a minor-leaguer.) Maybe "multithreading embedded linux" just isn't your gig. But Software Development is an exceedingly wide field (as you well know; cf #2 above). Is your company broad enough that your can find another niche? In my last job I was hired as an embedded SW dev. (I had no experience in that realm, but I told them I was a "quick learner.") I quickly sank like a stone. But I kept working hard and kept looking for problems that I did know how to solve for them. As it turned out, I was gradually able to migrate into new responsibilities at which I could shine, and for which I eventually recieved considerable commendation. So maybe you need to re-brand yourself.

The point is: if you're slow, there's a reason. But, hey -- you're a software engineer, dude! Debug yourself!


问:
Storing escaped mysqli characters in database but outputting them correctly with htmlspecialchars()
I have a database sanitizing function that I use when the user enters some data into my website.  I escaping the mysqli characters with mysqli_real_escape_string(), but I wish to also output the content with htmlspecialchars().  The problem is, let's just say the user enters something with a single quote; that will be escaped by the sanitize function and will be output as \'.  Is there any way to store it like that, and then output it as '?</p>

答:
I have a database sanitizing function that I use when the user enters some data into my website.

If you use prepared statements, there is no need to do this.  There is nothing unsafe about having a value like "D'Alejandro" in a database column.

SQL injection problems arise when SQL statements are built by interpolating user-supplied values into the statement text.  There is no reason any modern web application should do this.


问:
Can C++ be used as a server-side web development language?
I'd like to get into web development using C++ as the "scripting language" on the server-side.  My server infrastructure is *nix based, so doing web development in C++ on Azure is not applicable and C++/CLI ASP.NET is also not applicable.

Separate from legacy CGI applications, can web development be done using C++ ?

答:
For PHP you can write your own C/C++ extensions and get good performance benefits that way. If I had a really CPU intensive part of my web application I would probably make a small C++ library that offloaded that processing to the extension and then returned the result back to the PHP and then the PHP outputs it to the browser.

The other thing people don't often consider is offloading certain CPU processing to the client side e.g. JavaScript/jQuery. If I've got a web server, I might need a a 3Ghz CPU to do CPU intensive processing for a particular function (maybe some data processing). My company is paying money for that server each month to keep it running. If I want to scale up operations for a 100 concurrent users running that CPU intensive task at the same time then maybe I need multiple CPUs and servers, increasing the cost to my business. If I offload that CPU intensive task to the client side, then each user that visits the website can do their own processing on the data and I don't have to increase my server capability therefore saving me money.

After all with all with the collective power of 100+ desktops/tablets/mobiles doing the processing for you that's a lot more power than your server sitting in a datacenter somewhere costing your business money each month to keep running. Potentially then all your server would be doing would be retrieving data from the database, serving content and a bit of pre/post processing and validation of the data before storing back in the database. Obviously you wouldn't make the client side code too CPU intensive which might block/freeze the web browser UI, you might fire off an AJAX request to the server, retrieve the data and then process the data asynchronously client-side, leaving the web-browser UI completely usable.


问:
Find the count of each word in a string
I am in a search of a better performant algorithm to implement a program, to find the count of each word in a sentence i.e.., a String in the programming sense.

I know my algorithm is too basic and Noob. Here's my algorithm.

Read the String.

Tokenize the String with the delimiter, put each token in a list(ArrayList).

Iterate the generated list, in each iteration compare the current string with every other string of the list, if it matches increase the count of this string.

For each iteration, put the String and its count in a map.

Iterate the map and display, with key as string and value as its count.

What is the best approach than this?

答:
The trick is to use the right data structure for the job, and in this case the right data structure is a multiset. In fact, the multiset is the answer, you don't even need an algorithm.

Here's an example in Ruby:

```<code>require 'multiset'

s = 'Hello World Hello Programming Hello World'

Multiset.new(s.split)
# => #<Multiset:#3 "Hello", #2 "World", #1 "Programming">
</code>```

Title: Find the count of each word in a string

Body:
The trick is to use the right data structure for the job, and in this case the right data structure is a multiset. In fact, the multiset is the answer, you don't even need an algorithm.

Here's an example in Ruby:

require 'multiset'

s = 'Hello World Hello Programming Hello World'

Multiset.new(s.split)
# => #<Multiset:#3 "Hello", #2 "World", #1 "Programming">


问:
Is there a point to unit tests that stub and mock everything public?
When doing unit tests the "proper" way, i.e. stubbing every public call and return preset values or mocks, I feel like I'm not actually testing anything. I'm literally looking at my code and creating examples based on the flow of logic through my public methods. And every time the implementation changes, I have to go and change those tests, again, not really feeling that I'm accomplishing anything useful (be it mid- or long-term). I also do integration tests (including non-happy-paths) and I don't really mind the increased testing times. With those, I feel like I'm actually testing for regressions, because they have caught multiple, while all that unit tests do is show me that the implementation of my public method changed, which I already know.

Unit testing is a vast topic, and I feel like I'm the one not understanding something here. What's the decisive advantage of unit testing vs integration testing (excluding the time overhead)?

答:
The unit tests with mocks are to make sure the implementation of the class is correct.  You mock the public interfaces of the dependencies of the code that you are testing.  This way you have control over everything external to the class and are sure that a failing test is due to something internal to the class and not in one of the other objects.

You are also testing the behavior of the class under test not the implementation.  If you refactor the code (creating new internal methods, etc) the unit tests should not fail.  But if you are changing what the public method does then absolutely the tests should fail because you have changed the behavior.

It also sounds like you are writing the tests after you have written the code, try instead writing the tests firsts.  Try outlining the behavior that the class should have and then write the minimum amount of code to make the tests pass.

Both unit testing and integration testing are useful for ensuring the quality of your code.  The unit tests examine each component in isolation.  And the integration tests make sure that all the components interact properly.  I want to have both types in my test suite.

Unit tests have helped me in my development as I can focus on one piece of the application at a time.  Mocking the components that I haven't made yet.  They also a great for regression, as they document any bugs in the logic that I have found (even in the unit tests).

UPDATE

Creating a test that only makes sure that methods are called has value in that you are making sure that the methods actually do get called.  Particularly if you are writing your tests first, you have a check list of methods that need to happen.  Since this code is pretty much procedural, you don't have much to check other than that the methods get called.  You are protecting the code for change in the future.  When you need to call one method before the other.  Or that a method always gets called even if the initial method throws an exception.

The test for this method may never change or may change only when you are changing the methods.  Why is this a bad thing?  It helps reinforce using the tests.  If you have to fix a test after changing the code, you will get in the habit of changing the tests with the code.


答:
What's the decisive advantage of unit testing vs integration testing?

That's a false dichotomy.

Unit testing and integration testing serve two similar, but different purposes.  The purpose of unit testing is to make sure your methods work.  In practical terms, the unit tests make sure that the code fulfills the contract outlined by the unit tests.  This is evident in the way that unit tests are designed: they specifically state what the code is supposed to do, and assert that the code does that.

Integration tests are different.  Integration tests exercise the interaction between software components.  You can have software components that pass all of their tests and still fail integration tests because they don't interact properly.

However, if there is a decisive advantage to unit tests, it is this: unit tests are much easier to set up, and require far less time and effort than integration tests.  When used properly, unit tests encourage the development of "testable" code, which means the final result is going to be more reliable, easier to understand, and easier to maintain.  Testable code has certain characteristics, like a coherent API, repeatable behavior, and it returns results that are easy to assert.

Integration tests are more difficult and more expensive, because you often need elaborate mocking, complex setup, and difficult assertions.  At the highest level of system integration, imagine trying to simulate human interaction in a UI.  Entire software systems are devoted to that sort of automation.  And it is automation that we're after; human testing is not repeatable, and doesn't scale like automated testing does.

Finally, integration testing makes no guarantees about code coverage.  How many combinations of code loops, conditions and branches are you testing with your integration tests?  Do you really know?  There are tools that you can use with unit tests and methods under test that will tell you how much code coverage you have, and what the cyclomatic complexity of your code is.  But they only really work well at the method level, where unit tests live.

If your tests are changing every time you refactor, that's a different problem.  Unit tests are supposed to be about documenting what your software does, proving that it does that, and then proving that it does that again when you refactor the underlying implementation.  If your API changes, or you need your methods to change in accordance with a change in the system design, that's what is supposed to happen.  If it's happening a lot, consider writing your tests first, before you write code.  This will force you to think about the overall architecture, and allow you to write code with the API already established.

If you're spending a lot of time writing unit tests for trivial code like

```<code>public string SomeProperty { get; set; }
</code>```

then you should reexamine your approach.  Unit testing is supposed to test behavior, and there is no behavior in the line of code above.  You have, however created a dependency in your code somewhere, since that property is almost certainly going to be referred to elsewhere in your code.  Instead of doing that, consider writing methods that accept the needed property as a parameter:

```<code>public string SomeMethod(string someProperty);
</code>```

Now your method doesn't have any dependencies on something outside of itself, and it is now more testable, since it is completely self-contained.  Granted, you won't always be able to do this, but it does move your code in the direction of being more testable, and this time you're writing a unit test for actual behavior.

Title: Is there a point to unit tests that stub and mock everything public?

Body:
When doing unit tests the "proper" way, i.e. stubbing every public call and return preset values or mocks, I feel like I'm not actually testing anything. I'm literally looking at my code and creating examples based on the flow of logic through my public methods. And every time the implementation changes, I have to go and change those tests, again, not really feeling that I'm accomplishing anything useful (be it mid- or long-term). I also do integration tests (including non-happy-paths) and I don't really mind the increased testing times. With those, I feel like I'm actually testing for regressions, because they have caught multiple, while all that unit tests do is show me that the implementation of my public method changed, which I already know.

Unit testing is a vast topic, and I feel like I'm the one not understanding something here. What's the decisive advantage of unit testing vs integration testing (excluding the time overhead)?

Body:
What's the decisive advantage of unit testing vs integration testing?

That's a false dichotomy.

Unit testing and integration testing serve two similar, but different purposes.  The purpose of unit testing is to make sure your methods work.  In practical terms, the unit tests make sure that the code fulfills the contract outlined by the unit tests.  This is evident in the way that unit tests are designed: they specifically state what the code is supposed to do, and assert that the code does that.

Integration tests are different.  Integration tests exercise the interaction between software components.  You can have software components that pass all of their tests and still fail integration tests because they don't interact properly.

However, if there is a decisive advantage to unit tests, it is this: unit tests are much easier to set up, and require far less time and effort than integration tests.  When used properly, unit tests encourage the development of "testable" code, which means the final result is going to be more reliable, easier to understand, and easier to maintain.  Testable code has certain characteristics, like a coherent API, repeatable behavior, and it returns results that are easy to assert.

Integration tests are more difficult and more expensive, because you often need elaborate mocking, complex setup, and difficult assertions.  At the highest level of system integration, imagine trying to simulate human interaction in a UI.  Entire software systems are devoted to that sort of automation.  And it is automation that we're after; human testing is not repeatable, and doesn't scale like automated testing does.

Finally, integration testing makes no guarantees about code coverage.  How many combinations of code loops, conditions and branches are you testing with your integration tests?  Do you really know?  There are tools that you can use with unit tests and methods under test that will tell you how much code coverage you have, and what the cyclomatic complexity of your code is.  But they only really work well at the method level, where unit tests live.

If your tests are changing every time you refactor, that's a different problem.  Unit tests are supposed to be about documenting what your software does, proving that it does that, and then proving that it does that again when you refactor the underlying implementation.  If your API changes, or you need your methods to change in accordance with a change in the system design, that's what is supposed to happen.  If it's happening a lot, consider writing your tests first, before you write code.  This will force you to think about the overall architecture, and allow you to write code with the API already established.

If you're spending a lot of time writing unit tests for trivial code like

public string SomeProperty { get; set; }

then you should reexamine your approach.  Unit testing is supposed to test behavior, and there is no behavior in the line of code above.  You have, however created a dependency in your code somewhere, since that property is almost certainly going to be referred to elsewhere in your code.  Instead of doing that, consider writing methods that accept the needed property as a parameter:

public string SomeMethod(string someProperty);

Now your method doesn't have any dependencies on something outside of itself, and it is now more testable, since it is completely self-contained.  Granted, you won't always be able to do this, but it does move your code in the direction of being more testable, and this time you're writing a unit test for actual behavior.


问:
Coding Style And defects
Over the years I have developed several style based techniques which I use to keep my from make Error if(const == lvalue) rather then if(lvalue == const) since the first can't fall victim to the classic accidental assignment goof.

I recently  worked on a project with very unusual style standards and I found that I had much greater difficulty reading code.  Has anyone seen any statistics on a particular coding style and its defect levels or have any experience with changing style alone to improve defect rates.

答: If you haven't read it yet, you should definitely take a look at Code Complete, 2nd Edition by Steve McConnell. Almost the entire book is devoted to this type of discussion along with actual studies to back up his ideas.</p>

ContentLicense: CC BY-SA 2.5

Title: Coding Style And defects


问:
Working in a company that does not comment their code at all?
I work for a small software development house (10~ developers, a few product managers and a few support staff) that sells various products and services to organisations internationally through resellers. I arrived in the job 7 months ago into a role opened up by a developer who left after 3 years. The company has maybe been around for 10 years. Basically they have about 30+ separate products (in 30 separate .NET solutions which may consist of 10+ projects within each of those solutions). I would estimate each project or solution to be of medium to large size.

In each project there is absolutely no source code comments at all. There's also no architecture diagrams or documentation for how the application is designed or the code hangs together. There's some business analysis (use case) type documentation for how the program is supposed to work, when it was first created, but that's it.

As a new person to the company, for the past 7 months I've been thrown into various projects and had to fix bugs in these various products. I have an IT degree and I'm perhaps intermediate-senior level in HTML5/PHP/web development, also junior-intermediate level in .NET development. They recruited me for my web development skills and wanted to progress my .NET skills. I accepted as it was paying more than my old job in PHP and thought it would be useful for my career and more job options to have some more .NET development background.

However each day I feel as though I'm floundering in the deep end and treading water. For starters to get anything done, reading the code is mostly pointless as you've got no baseline from where to start or find or fix a bug in this new project you've just been assigned. I end up talking to one of the other senior programmers to get an idea of where to start. By senior, I mean they've been there for 4 years and have a general idea of how a particular program might work. Even they didn't even write most of the software, a lot of it was written by a few older guys that have since retired and left the company.

The code itself is very complex in my opinion. Maybe it's just because I'm not that skilled in .NET but there seems to be lots of unnecessary layers of complexity. You might have your basic 3 layers for MVC. Then whoever wrote the application added in more layers of code for the project, maybe to structure the application. For example, the front controller calls a few classes which bootstraps the application, then that calls the controller, then a method there might call a model then that model calls a business layer, then that calls a business logic layer, then that calls a data layer, then the data layer calls a service which has more classes to call stored procedures and get the data from the database. This is a far cry from my experience in PHP which even in complex web apps would still be as simple as the front controller calling a controller which calls the model, the model retrieves data from the database and renders it to the view/webpage. I mean what benefit are all these extra layers adding?

Another thing, there might be a class, then they create an interface for just that class. There's no other classes using that interface or inheriting from it. They just create an interface for every class pretty much. As far as I can see there's no unit tests using the interfaces either. I'm sure it must've made sense to the senior developer writing it, but the meaning is lost on me.

The other thing they like to do is because they don't have many developers in house, they write up some specs/documentation for a system they want, then outsource the project to another company to develop. Then once it's finished they bring it back in house for the local developers to maintain it. One company they outsourced it to was a local development services company, but that company in turn outsourced the development efforts to some developing country. Now I'm back here maintaining their code base, and it doesn't have any comments either. The program itself is probably the size of say Photoshop as an example. There's literally multiple layers of complexity and large parts of the code are commented out in chunks. Why is it commented out? Do they think they'll use that code in the future? No idea. No-one else knows either. The people that worked on it in the outsourced company have since left that company and disappeared.

Early on when I joined the company, I was reading some convoluted project code and added some comments into the code so I could make sense of it later on if I had to come back to the project. A few days later one of the more senior developers there came and asked me some questions about that project. I found the thing he was trying to figure out was actually the thing I had figured out the other day. I had written a comment in the code explaining what it did and I showed him. Then he immediately deleted the comment without reading it, scrolled up the code and asked me another question. Then I said, well that can be explained in the comment below which you just deleted. He goes back and undoes the deletion then reads the comment... then he finally understands.

I asked him why none of the code has any comments and his rationale was that the comments get outdated and become pointless. Well yeah, comments are supposed to be maintained along with the code. You update the code, you update the comment at the same time. The development manager's rationale for no comments was that good code should be understandable without comments.

OK so they've got these hugely complicated systems and the only people that have some idea of how they work are the people that were there in the beginning or who have been working on them for many years. Basically if these people leave it would practically ruin the company in my opinion because no newcomers coming along will understand the code base and be able to maintain it.

When I get asked to do something there, like add a new feature into the system, I think I could probably knock it out in HTML5/jQuery/PHP in a few days no problem. In this company, I've got to first figure out the system, then understand how the code works with no comments, then figure out where to put my code, then code it. Days turn to weeks. It's like searching for a needle in a haystack.

My philosophy is to design and code something well the first time, in the simplest way possible to get the job done, while making the code easily maintainable and understandable so if a new person had to pick it up they can just run with it straight away. But that seems very contrary to what this company does.

So my questions:

Is not commenting code a common practice in the software industry?

Why is there so much aversion to commenting code?

How can I perform my job well in this environment?

Should I recommend they start commenting their code or leave them to it?

答:
Is not commenting code a common practice in the software industry?

Sadly, yes for most. I was one of those programmers who don't value writing comments to the code. I realized this when a fellow developer started doing it and it saved me a lot of time understanding the code. Now, I'm one of those programmers who write good comments.

Why is there so much aversion to commenting code?

Because they don't see the value of it yet and skeptical because it's outside of their comfort zone. Do it, to prove.

How can I perform my job well in this environment?

This is a very broad question. I suggest you start writing comments to the code yourself. Influencing them is one of the most effective ways.

Should I recommend they start commenting their code or leave them to
it?

Yes, but you must lead the effort. Don't wait for them. Yes we can teach them technical skills, but we can't teach them what to love.


答:
First reason: pressure

When you work under constant pressure, there is a choice:

Either you do things fast, by just coding, eventually using quick hacks, without thinking about the architecture, without writing documentation, without refactoring,

Or you spend more time doing quality work.

In too many companies, you'll be blamed in the second case, because it took you too much time to do the job, when your fellow colleagues could have done the same thing much faster. After a while, the company will eventually fire you.

Second reason: metrics

Things that matter are things which are actually measured. If a company starts rewarding developers by number of LOC they write per month, we'll see a growth of completely useless lines of code.

Since the quality of documentation is not a metric which is taken in account in your company, nobody will care documenting their code. Your colleagues will simply put their efforts into solving the business problem short term, no matter what technical debt they are creating, because management wants solutions right now.

Title: Working in a company that does not comment their code at all?

Body:
I work for a small software development house (10~ developers, a few product managers and a few support staff) that sells various products and services to organisations internationally through resellers. I arrived in the job 7 months ago into a role opened up by a developer who left after 3 years. The company has maybe been around for 10 years. Basically they have about 30+ separate products (in 30 separate .NET solutions which may consist of 10+ projects within each of those solutions). I would estimate each project or solution to be of medium to large size.

In each project there is absolutely no source code comments at all. There's also no architecture diagrams or documentation for how the application is designed or the code hangs together. There's some business analysis (use case) type documentation for how the program is supposed to work, when it was first created, but that's it.

As a new person to the company, for the past 7 months I've been thrown into various projects and had to fix bugs in these various products. I have an IT degree and I'm perhaps intermediate-senior level in HTML5/PHP/web development, also junior-intermediate level in .NET development. They recruited me for my web development skills and wanted to progress my .NET skills. I accepted as it was paying more than my old job in PHP and thought it would be useful for my career and more job options to have some more .NET development background.

However each day I feel as though I'm floundering in the deep end and treading water. For starters to get anything done, reading the code is mostly pointless as you've got no baseline from where to start or find or fix a bug in this new project you've just been assigned. I end up talking to one of the other senior programmers to get an idea of where to start. By senior, I mean they've been there for 4 years and have a general idea of how a particular program might work. Even they didn't even write most of the software, a lot of it was written by a few older guys that have since retired and left the company.

The code itself is very complex in my opinion. Maybe it's just because I'm not that skilled in .NET but there seems to be lots of unnecessary layers of complexity. You might have your basic 3 layers for MVC. Then whoever wrote the application added in more layers of code for the project, maybe to structure the application. For example, the front controller calls a few classes which bootstraps the application, then that calls the controller, then a method there might call a model then that model calls a business layer, then that calls a business logic layer, then that calls a data layer, then the data layer calls a service which has more classes to call stored procedures and get the data from the database. This is a far cry from my experience in PHP which even in complex web apps would still be as simple as the front controller calling a controller which calls the model, the model retrieves data from the database and renders it to the view/webpage. I mean what benefit are all these extra layers adding?

Another thing, there might be a class, then they create an interface for just that class. There's no other classes using that interface or inheriting from it. They just create an interface for every class pretty much. As far as I can see there's no unit tests using the interfaces either. I'm sure it must've made sense to the senior developer writing it, but the meaning is lost on me.

The other thing they like to do is because they don't have many developers in house, they write up some specs/documentation for a system they want, then outsource the project to another company to develop. Then once it's finished they bring it back in house for the local developers to maintain it. One company they outsourced it to was a local development services company, but that company in turn outsourced the development efforts to some developing country. Now I'm back here maintaining their code base, and it doesn't have any comments either. The program itself is probably the size of say Photoshop as an example. There's literally multiple layers of complexity and large parts of the code are commented out in chunks. Why is it commented out? Do they think they'll use that code in the future? No idea. No-one else knows either. The people that worked on it in the outsourced company have since left that company and disappeared.

Early on when I joined the company, I was reading some convoluted project code and added some comments into the code so I could make sense of it later on if I had to come back to the project. A few days later one of the more senior developers there came and asked me some questions about that project. I found the thing he was trying to figure out was actually the thing I had figured out the other day. I had written a comment in the code explaining what it did and I showed him. Then he immediately deleted the comment without reading it, scrolled up the code and asked me another question. Then I said, well that can be explained in the comment below which you just deleted. He goes back and undoes the deletion then reads the comment... then he finally understands.

I asked him why none of the code has any comments and his rationale was that the comments get outdated and become pointless. Well yeah, comments are supposed to be maintained along with the code. You update the code, you update the comment at the same time. The development manager's rationale for no comments was that good code should be understandable without comments.

OK so they've got these hugely complicated systems and the only people that have some idea of how they work are the people that were there in the beginning or who have been working on them for many years. Basically if these people leave it would practically ruin the company in my opinion because no newcomers coming along will understand the code base and be able to maintain it.

When I get asked to do something there, like add a new feature into the system, I think I could probably knock it out in HTML5/jQuery/PHP in a few days no problem. In this company, I've got to first figure out the system, then understand how the code works with no comments, then figure out where to put my code, then code it. Days turn to weeks. It's like searching for a needle in a haystack.

My philosophy is to design and code something well the first time, in the simplest way possible to get the job done, while making the code easily maintainable and understandable so if a new person had to pick it up they can just run with it straight away. But that seems very contrary to what this company does.

So my questions:

Is not commenting code a common practice in the software industry?

Why is there so much aversion to commenting code?

How can I perform my job well in this environment?

Should I recommend they start commenting their code or leave them to it?


答:
First of all,
if such a small company is able to produce and maintain 30 successful products, then there's a high chance they understand what they are doing and have smart people working.

Secondly, there are different kinds of people. Some people do not like change, some people are strongly opinionated on some concepts.

Thirdly,  you mentioned that if the code would be commented, you will spend days, not weeks working on a feature. I think you overestimate the power of comments.

As per your questions:

 1. Is not commenting code a common practice in the software industry?
Just search this site..

 - "Comments are a code smell"

 - Are outdated comments an urban myth?

 -To summarize: Code comments are a useful tool, but they have to be maintained and be as clear as possible.

 2. Why is there so much aversion to commenting code?

 -Ask your coworkers.

3. Should I recommend they start commenting their code or leave them to it?

 -If you believe that commenting the code will help your work, then yes - you should. You should always have clear communication with your team members.

And it's a gradual process of building trust.


答:
There are a lot of reasons for no comments, but I think it usually boils down to incompetence, poor communication skills, and/or amateurism.

Is not commenting code a common practice in the software industry?

Only the bad areas of the industry; bad code rarely has enough comments, just as good code rarely has too many.

Why is there so much aversion to commenting code?

There's not. If anything, there seems to be more and more tools to support better, more effective commenting. This may sound sinister, but I've known a few bad developers that leave comments out for job security - they don't want other people understanding their code. Fortunately, the best developers think this is fickle and refrain.

How can I perform my job well in this environment?
  Should I recommend they start commenting their code or leave them to it?

I think the bigger question is, does it matter? Let's say that you somehow do a great job and everyone's writing comments. Great, now what? Well then you're at the starting line and can finally start improving the code for your customers now that everyone understands the code; if you had such a hard time with something as easy as comments, is it likely you'll find success here?

Personally, I've found that the level of confusion one experiences on a project is a pretty accurate measure of competence - inversely proportional of course. I think as a developer trying to grow, it would be easy to think the confusion is due to your own incompetence, but think about this: would a strong team hire someone and then let them drown in an ocean of confusion? No! They'll empower the new guy so he can return the favor.

I've experienced similar situations first- and secondhand. Typically, the developer is either in over their head or in a tar pit. I think the response to you asking them about the lack of comments is most telling in this case:

... the comments get outdated and become pointless.

No, because refactoring comments and documentation is part of refactoring code! You're spot on.

... good code should be understandable without comments.

Mostly true, but then why did we just have this dialog?


问:
Design patterns: Extract instance types into different buckets
I have the following type hierarchy:

```<code>interface I:
    ----+class B implements I
    ----+class C implements I
    ----+class D implements I
</code>```

I have another class Consumer1 that supports types C and D but not B (in its various methods) and a class Consumer2 that supports type B. I have total control over Consumer1 and Consumer2 so I can choose how to implement them. Now, at runtime I expect my callers to give me a collection of Is and I will decide internally whether to route them to Consumer1 or Consumer2.

Now, a very bad non-OOP way is to do an if instanceof check all over the place and mess things up. One alternative is to register a supporting class Map<Class<?>, Class<?>> that shall contain {{B,Consumer2}, {C,Consumer1}, {D,Consumer1}}. This is as bad as the previous one because I shall have to cast objects after figuring out whether to send them to Consumer1 or Consumer2.

A second alternative is to apply a Visitor pattern which would solve this rather neatly but prevent my interface from being extended further (unless I modify the visitor). Is there a neater alternative?

答:
I think Chain of responsibility is best fit for this problem. This will make it properly extensible, while encapsulating eventual instanceof calls into the consumer themselves.

To add to this. I don't think using instanceof is wrong. It just needs to be properly encapsulated, just like in this case.


问:
What is the proper and easy way to move a LocalDB to Azure using code first ?
The only way I could figure how to do it was create the schema on the localDB with code first  and then manually change the database string to Azure and then run the code on Azure..  But that only gives me the schema and not the data..

Is there a better way like ? bacpac? Create a script instead? Or some other concept I am missing ?

答:
Generating a script for just data from SQL Server Management Studio should work fine, but for a large amount of data you may have to save the script into a file and run it from the command line. This method will not allow you to synchronize changes made after the initial migration.

There are some excellent professional tools for dealing with this problem. I use Redgate's SQL Data Compare to synchronise data from a local database to SQL Azure, which can either generate a script of the differences or update the target database itself.


问:
Does anyone prefer proportional fonts?
I was reading the wikipedia article on programming style and noticed something in an argument against vertically aligned code:

Reliance on mono-spaced font; tabular
  formatting assumes that the editor
  uses a fixed-width font. Most modern
  code editors support proportional
  fonts, and the programmer may prefer
  to use a proportional font for
  readability.

To be honest, I don't think I've ever met a programmer who preferred a proportional font.  Nor can I think of any really good reasons for using them.  Why would someone prefer a proportional font?

答: Personally I don't care. As long as you keep my tabs aligned and the font legible, I couldn't care less whether I use monospace, proportional, or some other off-the-wall spacing. Just don't start substituting my tabs with spaces, and you'll have no quarrel with me.</p>

Title: Does anyone prefer proportional fonts?


答:
I'm going to go against the grain a bit here.

You're clearly new to C# development (as you admitted), and are used to the "everything in one file" approach that's often promoted in PHP. This is absolutely not the way to develop C# applications with a long-term view about maintenance and extensibility.

I've seen plenty of very well-commented code that was atrocious, 5000 line methods with multiple exit points and scattered data access in the back-end code of an ASP.NET web page. Comments are utterly useless in a scenario like this, since you'll still spend hours trying to work out where to look when fixing an issue or extending the product.

I've also worked on huge applications with almost no commenting, but with carefully thought through method and class names, a standardised approach to architecture, and with developers who are happy to spend the time talking to each other to find where to look for an issue (or who can figure out where to look simply by the naming of the classes and their relationship with the UI). This approach has resulted in much stabler, better-tested, and easier to maintain applications.

Comments, and architecture diagrams, are simply a form of communication, and communication is really the most important thing. How that communication is delivered, whether via talking to other devs, sensibly and consistently named types and variables, or through comments, is irrelevant, as long as the developers you are working with are comfortable with the code.

By your description, you're working at a place that has a fairly sensible method of architecting their applications with well-separated components, and this type of development is often the holy grail of dev houses, whereas the do-it-quick PHP-style approach you stated a preference for is great in the short term but causes innumerable problems in the long term.

TLDR; You're asking the wrong question; commenting the code is not necessarily the best way to communicate the design of the application in the particular environment you've found yourself working in. I would suggest trying to find a mentor from the more senior staff that you work with, and get them to guide you in how they work. It might not be how you're used to working, but that does not mean that they're wrong.

As for the actual commenting: the best code does not need comments to explain how it works, only the odd comment to explain why it works how it does. It'll explain how it works with type names, variable names, and an existing understanding of the patterns that are used.

Is not commenting code a common practice in the software industry?
Yes, sometimes for good reason, sometimes not.

Why is there so much aversion to commenting code?
It can be time-consuming, and is often unnecessary.

How can I perform my job well in this environment?
Find a mentor, learn from them.

Should I recommend they start commenting their code or leave them to it?
I'd wait until you understand the patterns they're using before trying to make any changes.


答:
Is not commenting code a common practice in the software industry?

Well written code needs few comments (if any) but this is often taking as carte blanche for any cowboy to just hack some code together

Why is there so much aversion to commenting code?

It is extra time and code which isn't obvious to you might be obvious to someone else. I suspect this is what happened with you when a more senior guy took your comments out. It is also something else to change when the code changes

How can I perform my job well in this environment?

If you don't want to stay, then quit. Otherwise, just learn all you can

Should I recommend they start commenting their code or leave them to it?

This is up to you, but it sounds as though some other helpful soul will just take them out


问:
How to modularize and package a client-side Javascript library today?
I've been catching up with the modern client-side JS ecosystem and reading up on CommonJS and AMD (incl. associated tools - browserify, requirejs, onejs, jam, dozens of others).  If I'm writing a Javascript library, how do I modularize/package it such that it can be most broadly accessible (ideally by users who swear by CommonJS, AMD, and especially neither)?

Popular libraries like jQuery seem to just use old-school file concatenation for building itself and dynamically detect whether it should write to an exports or the global context.  I'm currently doing the same thing, but the main downside is that if I (unlike jQuery) depend on a few libraries, it's nice to not have to ask users to manually pre-include the transitive set.  (Though I currently just have two dependencies.)  And of course global namespace pollution.

Or perhaps it's cleanest to generate multiple versions of my library, for each context?

I'm also wondering about packaging and publishing.  There are several systems, but I believe the major one is bower, which is easy to deal with since all it does is fetch.  However, I'm wondering if I should also be targeting other package systems like component (which requires CommonJS).

Are there other relevant aspects I should be aware of?  Are there any good example projects to follow for all of this?

答:
Kinds of client-side libraries:

Touches DOM

Doesn't touch DOM

With the first kind (UI widgets etc), you will typically assume jQuery is present. You can also
write "DOM library agnostic" and have it work with the less popular ones as well but I don't bother.

With the second kind. First of all, don't make it a jQuery plugin, for example "jQuery cookie plugin" is ridiculous but
such a library actually exists.

Both of these kinds might have no dependencies, small dependencies or huge dependencies - with a dom library not counting as a dependency in this sense.
With the first 2, you would just concatenate them inside your library scope and not worry about possible duplication. For example, jQuery concatenates
an internal isArrayLike function, even though the user might have his own already included from some random utility belt library.

I only have one personal experience with a huge dependency when developing a library (actually a language) - moment.js. In this case I would provide 2 builds,
one with moment.js concatenated and one without, where the user is responsible for including it. I don't know if this is a good solution though.

And yes, in every case, the jQuery approach of building one final big file that just works is taken. It has the module boilerplate at bottom (require/AMD/global etc detection).


问:
Web application using JSF-Front end and node.js-Back end
I'm planning to build a eCommerce web application(similar to http://zovi.com/) using JSF 1.2 and node.js. All front end components will be jsf components binding to backing bean. I want to achieve real time functionality ( such as displaying Today's hot sellers ,Customers who viewed this item also viewed such patterns) using node.js. And all data retrievals from database(MySQL)should be accomplished using node and display in JSF components. I'm confused in how to bind data that i get from node to corresponding managed bean property(since i bound it to corresponding JSF component).

For example on load I've to retrieve data using node.js and populate datatable component and also i should update backing bean. Is it possible with out using any web services like REST
Hope you understand this context. Please suggest some solutions.

And I heard performance of Node.js is efficient only for small web applications not for Enterprise level. Is my approach correct??

答:
To understand this approach is to be familiar with the goals and advantages that each of these very different frameworks take.

Node.js is a server side solution for efficient middle tier development of a web application.  Some advantages of this are that client and server code can be written in the same language allowing the domain model to exist, without translation, between client and server.

JSF is a component based web framework that allows for MVC development, and allows for a server side event model that can occur on user interaction with the client.

If you had to integrate them then ask yourself why you would need to?  JSF will allow you to define your client view and server side controller simultaneously so why would you have need for a second controller in Node.js?  If you decided to go with the Node.js approach then while your server side needs are met, your view still needs to be addressed which coincidentally allows you more control over the presentation of your web application than JSF typically allows.

Assuming you need to do this, the best way is to have Node.js provide business logic and data access to your separate JSF application through the use of REST based web services.  I would implement a wrapper around the Node.js web services and make these wrapper calls within my JSF Managed Beans.

The only reason I see for this approach is

If there exists a compelling business reason, like if data can only be accessed through a third party REST based web service that happens to be implemented in Node.js, or if you need to integrate with a component that a separate development group is responsible for.

If you wish to learn both technologies and do not have enough time to learn them each separately.


问:
Updating copyright headers each new year just because Jan 1st has passed?
I've seen some projects that - with each new year - start to change all files in their source-tree to update the copyright year.

Isn't this just pushing hot air on a level of magnitude? AFAIK:

Copyright year is based on relevant changes of a work (also) - not only because of a trivial change of the copyright year in a file-header that is the only change.

Changing nearly all files without an actual need brings the code out of order in version control.

I can't help myself but have problems to see why someone wants to do such superfluous stuff, albeit I know some projects are doing this (for example Zend Framework 1 in 2012).

Is there any use in changing the copyright year in each file only because Jan 1st has passed?

答:
"All problems in computer science can be solved by another level of indirection." (quote source)

In one of my past projects, we once got such kind of requirement. It has been solved once and forever by inserting a "copyright placeholder" into source code stored under version control:

```<code>    // %%COPYRIGHT PLACEHOLDER%%
</code>```

Whenever any change in that text was required, for whatever reason, we simply modified copyright template containing actual copyright text in our release scripts, so that published code has gotten that template inserted instead of placeholder.

Easy peasy, and programmers didn't waste their time trying to figure is there any use in changing the copyright.

Body:
"All problems in computer science can be solved by another level of indirection." (quote source)

In one of my past projects, we once got such kind of requirement. It has been solved once and forever by inserting a "copyright placeholder" into source code stored under version control:

    // %%COPYRIGHT PLACEHOLDER%%

Whenever any change in that text was required, for whatever reason, we simply modified copyright template containing actual copyright text in our release scripts, so that published code has gotten that template inserted instead of placeholder.

Easy peasy, and programmers didn't waste their time trying to figure is there any use in changing the copyright.