Why Is Using '<<-' Frowned Upon and How to Avoid It

Why is using ` -` frowned upon and how can I avoid it?

First point

<<- is NOT the operator to assign to global variable. It tries to assign the variable in the nearest parent environment. So, say, this will make confusion:

f <- function() {
    a <- 2
    g <- function() {
        a <<- 3
    }
}

then,

> a <- 1
> f()
> a # the global `a` is not affected
[1] 1

Second point

You can do that by using Reduce:

Reduce(function(a, b) {a[a==b] <- a[a==b]-1; a}, 2:6, df)

or apply

apply(df, c(1, 2), function(i) if(i >= 2) {i-1} else {i})

But

simply, this is sufficient:

ifelse(df >= 2, df-1, df)

Whats the name of this pattern and is frowned upon?

It's called fluent interface pattern.

Often applied in builder pattern aka fluent builder.

http://www.martinfowler.com/bliki/FluentInterface.html

As to second part of the question:

Pros:

1. Code readability and conciseness - it reflects what the code really
   does, like DSL

Cons:

1. Problems with debuging
2. Problems wih logging
3. The command query separation mentioned in the link above gets broken

For more: http://en.wikipedia.org/wiki/Fluent_interface

The are probably some more aspects I didn't cover though

Any Reason why Bare-Except's are Frowned Upon

Your example is a wonderful example of why this is a bad idea. Your program is not "if the data is nonexistent or corrupt, overwrite it with a template". Your program is "if anything at all goes wrong, try to overwrite the data with a template".

For example, if you had a typo in the code that gets executed while trying to load the data, your program will not inform you, and instead overwrite all of your (valid!) data with the template. This could be a rather disastrous bug, both in terms of lost data, and how easily you can convince yourself that this couldn't possibly be the problem, should the typo occur in an infrequently exercised code path that your test cases miss.

Another example of things going wrong is if the user decided to try and abort the program with Ctrl+C. You'd catch the KeyboardInterrupt and promptly clobber all of his data.

Why is python list comprehension sometimes frowned upon?

List comprehensions are used for creating lists, for example:

squares = [item ** 2 for item in some_list]

For loops are better for doing something with the elements of a list (or other objects):

for item in some_list:
    print(item)

Using a comprehension for its side effects, or a for-loop for creating a list, is generally frowned upon.

---

Some of the other answers here advocate turning a comprehension into a loop once it becomes too long. I don't think that's good style: the append calls required for creating a list are still ugly. Instead, refactor into a function:

def polynomial(x):
    return x ** 4 + 7 * x ** 3 - 2 * x ** 2 + 3 * x - 4
result = [polynomial(x) for x in some_list]

Only if you're concerned about speed – and you've done your profiling! – you should keep the long, unreadable list comprehension.

Why is pattern matching in an if statement frowned upon?

Like the other posters have said it is less idiomatic and can cause some trouble analyzing (or common erros like typing = instead of ==). My main argument for this are the following cases:

if get_status = :ok do 
  # Some code
else
  # Some other code

this is very limiting and not very expressive, with cond do you may do the following:

cond get_status do
  :ok -> # Some code
  :not_ok -> # Some other code
  _ -> # More code
end

If conditions are pretty much binary, you either get A or get something else. This is good if the result is a boolean from a local function call or similar, but if you are working on a distributed system, getting info from another machine or similar, cond do is much more powerful, concise and helps you reason and set up code for unexpected behaviour (the underscore in the above code, if get_status is a function that gets the status of a certain service that we expect something like :ok for the service being ready and :not_ok if the service is not ready, then what about if the service's machine is down? or maybe our network cable disconnected?).

Of course this can be achieved with multiple if statements, but that leads to poor code that is not very readable or maintainable.

---

Related Topics