Skip to Content
Personal Insights
Author's profile photo Nabheet Madan

The Magic 80 Char limit which used to exist for developers

When we started coding in our school days, we have always been told to keep width of code to 80 characters. I never questioned it. I was like if teacher say’s 80 then it is 80.  In fact when we started coding in ABAP the same was recommended to us by our tutors. So, this magic 80 character’s width stayed with me for a long time.

Off late we have see an amazing guide Clean ABAP helping us how do we write clean code. I thought of checking what does Clean ABAP has to say about this Magic number 80. I just searched through the guide and under “Stick to a reasonable line length” section found a mention of it.

What it mentions now is to follow a maxim length of 120 Characters and also gave some hint regarding the origins of 80 character limit.

That is all what triggered me to go down the memory lane and understand from where this 80 character’s limit came from.

80 Character Initial Origins

The 80 character’s limit has its roots in IBM Punch Card where the data or instructions were stored on card. The earlier days did not have any magnetic tapes and all to share data with other computers etc. You can only store Maximum 80 of Characters on the punch card.  As can be seem below in punch card you have 80 columns where each column represents a character.

Photo Credits –

So if a program needs to be stored on punch card an ABAP one practically one punch card would represent one line of card. Imagine the number of card’s you will need to store your program😊 Below is picture of lady who is holding 62500 punched cards which were used to create 1950s SAGE air defense system. This was all just 5 MB of data. Imagine if one of the card get misplaced the whole program fails, that all you will know once everything is loaded not like ours where we just compile and we get to know errors.

Photo Credits –

So at least now we know one of the origins from where this limit might have originated. Another place where the use of this limit could be seen was in earlier times terminals which were 80 columns width by default

Photo Credits –

So at least now we know what are the origins of this 80-character limit, the bigger question is Do we actually need a limit?

Do we need any such limit while coding?

Given the way things have changed I feel setting some ground rules for writing a clean code is important but not limits like these. Of course, if your team has limited screen width then it makes sense but these day does not look like it is needed. The call must be more of practical one, some of the logical scenarios which I can think of.

  • Shall we put one complete statement in one line? No if we can not see it all at one go better break it, make sure by breaking it should be readable😊

  • Shall we put multiple statements on one line? Yes, you can if statements are basic and related.

  • Does not matter what the limit is whether 80 or 132 or 200 at least it helps in adding uniformity to the code. Creating some rules helps in stopping people from arguing about inconsequential formatting rules, and get on with writing good, consistently formatted code.
  • Given the width of the screen’s which normally developer use, I think we can increase this limit like anything. If developer can keep two source code files open side by side along with folder explorer, it is amazing.


Feel free to provide your feedback and comments on the same.



Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Michael Biber
      Michael Biber

      Nice one thanks! And exactly my opinion.

      There are some limitations in the system for a line length of 72 characters:

      • Statements to read parts of a foreign report
      • Dump analysis ST22 has only a limited line length
      • Classic classic Debugger could only display 72 characters width (yes, a former colleague preferred that one)

      Maybe we can find more...

      Author's profile photo Lars Hvam
      Lars Hvam

      Both styleguide and SAP help documentation recommends max one statement per line,

      Author's profile photo Matthew Billingham
      Matthew Billingham

      I was going to point that out.

      In the example given in the text, at first glance it looks like all those variables are to be cleared. It's confusing.

      One statement. One (or more) lines.

      Author's profile photo Nabheet Madan
      Nabheet Madan
      Blog Post Author

      Sorry for causing the confusion , my point was here to just demonstrate we can lets say few of related initialization's for a particular function/method at one place as it will always remain the same.  It was more or less initializing things examples.

      Author's profile photo Nabheet Madan
      Nabheet Madan
      Blog Post Author

      Agree SAP recommends one statement per line, but I still feel trivial one can be combined in one row.

      PS: This more of my understanding in general by looking at different programming languages not just ABAP, SAP recommendations for sure are to be respected.

      Author's profile photo Jelena Perfiljeva
      Jelena Perfiljeva

      No, please just don't combine statements on one line, period. It solves nothing and it causes poor readability. Every time I see this in the code, I roll eyes and think what is wrong with this person that they can't hit Enter and then click Pretty Printer (or ADT equivalent).

      It's a completely unnecessary shortcut, let's not encourage it.

      Author's profile photo W E
      W E

      There is a character limitation at the ALV (FIELDCAT_MERGE) in older programs, here we should pay attention to the char limitation of 72.

      Author's profile photo Rich Brown
      Rich Brown

      Thanks for this post. I remember those 80 column cards. They were what we used along with the 80-column coding sheets back when I started in "data processing" 50 years ago! Of course we had to stop at 72 because the other 8 were reserved for the line numbers in case you dropped them all!


      Thanks for the memories.

      Author's profile photo Enno Wulff
      Enno Wulff

      Concerning punch cards...

      Imagine if one of the card get misplaced...

      When I started my apprenticeship at SIEMENS NIXDORF, someone told me the following story:

      There was a program written to punch cards (don't know what the exact wording is... 😊 ), well tested and sent to a customer in a foreign country.

      The customer complained that the program was not working.

      Program was tested again, "printed" and sent to the customer again.

      Again the customer complained...

      Several times.

      somewhen they found out what happened:

      Customs have checked the punch card delivery randomly, pulled one card out from the middle, inspected it, and put it back. Somewhere else... 🤦‍♀️😅

      Author's profile photo Joachim Rees
      Joachim Rees

      Nice read on the history of 80 character limit, thanks for sharing!

      It made me think of that one time, when not adhering to 72 character limit cause me problems in one specific case: I wrote about it here:


      Author's profile photo Brian Vanderwiel
      Brian Vanderwiel

      Interesting blog - thanks for sharing.

      I never understood the drive towards long lines.  They are soooo difficult to read quickly and as mentioned, it makes side-by-side code compares (which I use constantly) a massive pain.

      If it's a new framework or whole "set" of code, set your standards as you see fit.  But if you're working in a big project/company with existing systems that are supported by disparate/changing resources, basic standards needs to be more restrictive to avoid a mess.

      Similarly with syntax - stay consistent.  If you have hundreds or thousands of objects written in older syntax, don't drop new syntax in when making a small change to avoid a readability nightmare.

      Author's profile photo Theo Zimmermann
      Theo Zimmermann

      Fully agree - reading a program is cumbersome if you need to scroll horizontally, especially when debugging. Even if lines are fully visible, it is cumbersome if you need to move your head to scan along the lines.