What's the best way to change how my code looks?

Question

A long time ago the question avoiding Python multiline string indentation was asked. The question was well received with a score of 66 and 16 favourites. It was even answered by one of our previous mods (who deleted their answer).

However yesterday it popped up in the close queue where five out of five users voted to close the question. Later that day it was added to the reopen queue, one user selected to keep it closed, where a moderator mod-hammered it open, with an edit. This edit was noticed by Duga, and posted to chat. Where I noticed the question, agreed with the closure and voted to close it as broken, which started another review in the close queue. This lead to a user voting to close the question, and a different moderator mod-hammering to leave the question open.

It has also been reviewed in the past where all (3) reviewers in the queue elected to leave it open.

And has been reviewed again where 2 voted to close and 3 voted to leave it open.

In total it received:

• 9 Votes to close
• 1 Vote to keep closed
• 1 Vote to reopen
• 7 Votes to leave open

And so the votes so far have been:

• 9 People have voted in favour for the question to be closed.
• 7 People have counter-voted those close-votes to reopen or leave open the question.

---

To note the close reasons have changed since the question was originally posted. Here describes most of the story of the close reasons. Where, if you have 10k rep, you can also see all the changes to the close reasons here. And so we can see that when the question was posted it was when we had our previous close reasons:

1. Questions containing broken code or asking for advice about code not yet written are off-topic, as the code is not ready for review. After the question has been edited to contain working code, we will consider reopening it.
2. Questions must involve real code that you own or maintain. Pseudocode, hypothetical code, or stub code should be replaced by a concrete implementation. Questions seeking an explanation of someone else's code are also of-topic.
3. Questions must include the code to be reviewed. Links to code hosted on third-party sites are permissible, but the most relevant excerpts must be embedded in the question itself.

Where the broken code reason hasn't changed much:

Code not implemented or not working as intended: Code Review is a community where programmers peer-review your working code to address issues such as security, maintainability, performance, and scalability. We require that the code be working correctly, to the best of the author's knowledge, before proceeding with a review.

---

It seems like a lot of users think this question should be closed. However moderators have been mod-hammering it open.

Is the question on-topic or off-topic?

Answer 1

For a question to be on-topic:

• Is code included in my question?

  Yes.

• Am I an author or maintainer of the code?

  They probably are.

• Do I want the code to be good code?

  Yes.

• Is it actual code from a project rather than pseudo-code or hypothetical code?

  This is missing the stub code reason, and the code does look quite stubby to me:

  def usage():
  
      print(...)
  

• Do I want feedback about any or all facets of the code?

  No they just want the string indented. They don't want a code review as they are asking a specific question, with the code to just answer that question.

• To the best of my knowledge, does the code work as intended?

  I think we can all agree the second snippet doesn't work as intended, "this give different results".

  Since print is printing a string literal, it shouldn't matter where the literal comes from. And so if we move the literal out of the function both code blocks are the same.

  def usage(data):
      print(data)
  

  From this we can now test if the code works in the use cases provided. Which it doesn't. With the second string literal it doesn't work. And so it only passes one of the test cases.

  Worst case the code doesn't work as intended. This can be shown by performing the same unit tests on the accepted answer. Which shows both unittests working.

  def usage(data):
      print(textwrap.dedent(data))
  

  If you think string literals are code, then only the string literals matter. This means the question comes down to just the following. Which is a best practices in general question. Even without removing the unneeded code, the question is still a best practices in general question.

  I want to make this code:

  V = """
  Usage examples:
  
  Test deployment:
         $ fab [noinput] test deploy
  
  Staging deployment:
         $ fab [noinput] staging deploy
  
  Production deployment:
         $ fab [noinput] production deploy
  """
  

  to look more like this:

  V = """
          Usage examples:
          Test deployment:
              $ fab [noinput] test deploy
          Staging deployment:
              $ fab [noinput] staging deploy
          Production deployment:
              $ fab [noinput] production deploy
          """
  

  but this give different results. What is the best way of writing this?

---

And so:

• They don't want feedback about any or all facets of the code.

  They are asking how to de-indent indented multi-line string literals.

• The code doesn't work as intended.

  The code doesn't work with all intended input, as it fails some of the provided unit tests.

• The question is a generic question.

And so for these reasons it's off-topic according to the help center.

Answer 2

This question has nothing to do with improving anyhting. OP is clearly asking for a concrete solution and thus it should be closed. Only because a couple of people voted for it, doesn't mean it's ok to ask such questions.

I like the way Stack Overflow deals with similar situations by closing them and adding the Historical significance banner:

This question exists because it has historical significance, but it is not considered a good, on-topic question for this site, so please do not use it as evidence that you can ask similar questions here. More info: FAQ.

Answer 3

In my opinion, the question is clearly on-topic:

• the code is included in the question
• it is the author's code
• it is actual code from a project
• the code works
• the author wants it to be good code
• they want a review on any/all facets.

The only issue that can been be misinterpreted on this question is whether the author's (failed) attempt at a refactor is the code they want reviewed, or whether it is just to provide context.

In my opinion, they want their working code reviewed (the first block of code), and their broken code is just an example of what they have tried so far, to make the code more readable. Since their refactor attempt is just for context, and not for review, it should not count towards the on-topic debate at all.

It all boils down to what code they author wants reviewed, and what code is just there for context. It is, in my mind, clear, that the author says:

I want to make this code: (insert REAL code here) to look more like this: (insert EXAMPLE code here) but this give different results. What is the best way of writing this?

In other words, the second code block is not there to be reviewed at all (whether it works, or not).

In an attempt to make it clear that the second code block is only there to provide context, I added the block-quote markdown to it, to visually identify it as not there for review. I did this when editing it in the reopen review queue.

Answer 4

This is how I read the question

And why I think it is on-topic.

---

I have this code from a project of mine, that prints the usage to the user:

def usage():

    print(
        """
Usage examples:

Test deployment:
       $ fab [noinput] test deploy

Staging deployment:
       $ fab [noinput] staging deploy

Production deployment:
       $ fab [noinput] production deploy
""")

However, I don't like to read it this way. It would be better if I could write it in a way that makes it easier for the eyes, like with indentation. How can I make this code still print the same thing but make the code easier for the eyes?

---

• The current code does work.
• It is a complete method from a real project
• They want the code to look better

This is one of those questions that are on-topic on both Code Review and Stack Overflow.

Answer 5

Being the Moderator that gave the "Leave Open Hammer", I would like to say that, I saw that Rolf had already edited and reopened the question, meaning that he felt it should be reopened. And I trust Rolf to close something if it needs closing.

The code that the user provided in the first code block works, and that is the code that they want reviewed, not the code that doesn't work. The user wants the functionality of the first code block with the readability of the broken code block, or better readability than what is in the broken code block.

I looked at the question further to decide if this was indeed stub code, but I don't believe that it is. The code appears to be runnable by itself and as such is not "Pseudocode, hypothetical code, or stub code"