Commonly accepted best practice for using newlines [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

As an extremely jr Software Engineer, I'm trying to make sure I develop good habits. The challenge of using newlines when displaying output seems very simple (I'm sure to those who are seasoned), but how should they generally be used throughout a program that displays output in various places throughout code execution?

Example (assuming the language is java):

public class output
{
   public static String usage = "usage: message";

   public static void main(String[] args)
   {
      System.out.println("Starting program");
      checkData();
      System.out.println("Ending program");
   }

   public static void checkData()
   {
      System.out.println("Data checked");

      # Assuming this method causes an exception
      try
      {
         more code...
      }
      catch(IOException ioe)
      {
         System.out.println(ioe.getMessage());
         System.out.pritnln(usage);
      }
}

Clearly all of these messages would run together if everything were to be printed. So as a program grows, and seeing as though errors necessitate the need to output information as well, should newline characters be placed at the beginning, end, or wherever one decides throughout a program?

Answer 1

There is an advanced feature "aspect oriented programming". Spring framework has some built in stuff.

Try to search it, learn how to use it an add some anotation to the functions, it will handle the "entering to the function", "exiting the function" with a simple @MyLogStuff

Answer 2

Although, I see a lot of code that's written to log every entry and exit point from each and every method called it isn't one of the good programming practices (it's surprising to some).

The only scenario when you would find this information useful is when you're debugging an exception. But the trace of every method invoked before the exception was thrown is already available in the exception's stack trace which leaves this kind of logging redundant.

It's only at places where the exception handling is already questionable that it would help. For e.g, the usual approach of log and forget (to some this is what exception handling is) without giving any serious thought to whether the exception should get escalated or even halt execution or not, and the just plain horrible eating exceptions up with catch (exception e) {// nothing happened}.