Ways to write compact, readable and elegant codes (Requesting to those who have figured it out)

[koyelghosh]

Sheeba I am sorry I am not hijacking your post, as in this link. I am using this thread simply because in this post two codes already exist: One from a novice like me (with a lengthy code) and the other from an expert like Tom (which is very compact and elegant). May be both get the same job done but there is a drastic difference in the ease in readability and the amount of cognitive load (at least for beginners reading the code). So please allow me to ask the question (below) to 10 top contributors of all time (as per this link on 06th July, 2019).

@Reeza @ballardw @Tom @Astounding @Kurt_Bremser @Ksharp @PGStats @RW9 @art297 @Cynthia_sas 

• How do you coders think, when you are writing the code?
• What makes you write much compact codes?
• How do you coders see, (as put, in the movie Imitation Games, by Alan Turing), wrong/unnecessary connections in code and weed them out?
• What is the thought process?
• Why as a beginner, I fail to see compactness at times and tend to write longer codes?
• Is it just me or beginners, in general, tend to do like this (may be irrespective of any programming language)? It is only with time a coder matures!!

In nutshell, apart from gaining experience, is there some tips you (or others reading this post) can impart on beginners like me ... anything that will shorten my path to a more compact, clean and elegant looking codes?

I know experience has no substitute and no shortcuts are there for experience but still ..

If I missed out any body here then apologies but please chime in with your thoughts. I can not mention more than 10 names in a post.

Many thanks in anticipation.

[Kurt_Bremser · Accepted solution]

There is a certain amount of talent involved. You need to have a knack to recognize patterns in something that is written, and you need to be good at thinking in abstract symbols. When I was a kid (50+ years ago), newspapers or periodicals used to have tests like "is your kid suited to become a programmer", where you were supposed to determine the next number in a series and the like. I was quite good at those. I am an avid and quick reader, and doing most of my reading in an acquired language that happens to be "the" language in computing helps also.

But that's only part of it. Like Thomas Edison said, "Genius is 1 percent inspiration and 99 percent transpiration". Practice makes perfect, and in my case (and I think the same is true for everyone here whom you consider a "master coder") that means literally millions of lines of code I have read and/or written, in a multitude of languages. So I have seen neat tricks in other people's code, and that gives you a basis that, some day, will let you find "your" neat trick.

Playing around with codes (Maxim 4), and comparing different solutions for a given issue, will provide you with a feel for the more efficient.

Try to not see the code, but the rules behind it, the algorithm. See things as algorithms. Not "get on the bike", but "stand next to the bike, oriented perpendicular to it. Grab the handlebar. Lift your right leg to the right. Turn left. Drop right leg."

 Digging into the depths of the workings of a computer is also a good thing, eg knowing that comparisons (the hard CPU code behind an "if") are the most costly operations and need to be reduced as much as possible.

To tell you what my exact thought processes are while coding, I would probably need to be the subject of a study conducted by psychologists.

Bottom line is (I think), "do as much coding as possible, and time will see you improve". If the fun grows while you do that, you've probably got "it". If it tends to get more tedious and disappointing all the time, probably not.

[Cynthia_sas]

Hi:

  I agree with what everyone else has said, but mostly, what resonates with me is "try not to see the code, but the rules behind it, the algorithm. See things as algorithms". Yes, yes, yes.

  Understand WHAT you have to do first and WHAT you have to start with and WHAT you have to finish with. Then, take inventory -- can you produce what you need with a procedure, with a program, are there transformations that need to happen first? If so, exactly what are the transformations. And still, you're not writing code yet.

  Not just stand next to the bike, grasp the handlebars, but also, are you wearing your helmet? Do you need sunglasses? Do you have sandals on? Do you need to switch to shoes? Have you got your water?

  When I taught programming (in Fortran and SAS), we had students do a "flowchart" of the assignment first and turn it in for grading before they ever wrote a program. Every time, the people who did the flowchart first, (the ones who thought about the problem before writing code), wrote more elegant, more compact, more correct code. And you don't have to use formal flowchart symbols to think about your problem, but just putting your plan on paper, without code helps you see the overall pattern and helps to focus your attention on the process and the steps to get from the beginning to the desired result.

Cynthia

[PaigeMiller]

I may not address all of your points here ... but here goes ...

The only way to learn to write compact, readable and elegant codes is to write lots of SAS code and learn over time by using this forum and reading the documentation and attending conferences and learning from colleagues. No one knows every command available in SAS; those who know a lot of commands and who can write excellent code have been doing it for a long time and reading the documentation and so on.

Next, with regards to readable and elegant, I think most of this depends on how much time you have to perfect your code and document your code. If I am working on a project and have a heavy workload and I am writing code for one-time use, then my code will probably be inefficient and not elegant, but it will get the job done. If I am writing code that will be re-used over and over again, then I have to put more time into this activity to make the code more efficient and readable and to insert meaningful comments into my code.

Side story: about 12 years ago, I took a job where the person before me wrote huge long SAS programs, with no comments. Well actually, there was one comment in these tens of thousands of lines of code, a useless comment, that read something like this:

/***** ARGGGGGH! This doesn't work. ****/

Don't write comments like that.

To continue the story, it took me about 6 months to really get a feel for what this code was doing and how it was being done and where everything was stored. Somewhere in those 6 months of trying to figure things out, I saw a data step that was about 25 lines long, and initially I couldn't figure out what it was doing. So then I had to go through the data step line by line, with actual data, to see what this 25 lines of code was doing — it was adding up zeros and ones, to get a sum. Advice: Don't do that.

So, back to the main topic ... you can't become a good SAS coder overnight. You have to work at it. You have to continually be learning, and asking if there are better ways to do things.

[PaigeMiller]

Adding

@Kurt_Bremser has a link to his Maxims about good SAS coding techniques; you probably ought to read all of them and understand them all as well and adopt them in your work. Except for #23, which refers to #23, when it really should refer to #23.

[Astounding]

Experience goes a long way toward the answer.  The tendency is this.  With more experience, you know the tools to focus on for a question.  As a result, you don't get caught up in unproductive lines of thought, and the answers reflect that clarity.

Speaking for myself, I don't necessarily try to make my answers the most concise program possible.  I look at what the poster has presented as his attempt to program the answer.  Often, my answer involves making the least number of changes to the existing program because I'm more confident that the poster will understand the answer.  (What good is it to post a hashing solution for a poster who is having trouble with IF THEN statements?)  I don't always shoot for the methods that I would use if I were programming a solution for my own purposes, because I'm not confident that the poster can judge when the solution is valid and when it is not.

Often, I notice that the original poster has not thought the problem through, and doesn't appreciate either what the solution should look like or what the obstacles are or what the required details are.  I try to reply with questions that should be answered before the programming can begin, to help with the thought process that needs to take place as an initial step.  I can't tell you how many times I have suppressed the urge to reply to poorly detailed questions with:  "I'm baking a cake and I'm using flour and sugar and eggs.  But it's not coming out right.  What am I doing wrong?"  But there are some questions that I skip because they are too poorly detailed and some posters that I recognize as being lazy thinkers where I do skip their questions as well.  These days, I also tend to skip questions that have been answered many times before, and questions where I am confident many other posters will be able to supply a correct answer.

Most of the time, the thought process is to construct a direct route that a program would need to take, writing the code for that route, and then examining it.  It's rare that I would actually test the code.  Once I've written it, I do try to look it over to either correct it or improve it.  For the majority of questions (not for the current question, however), the entire process takes 5 minutes or less unless I need to look up a detail in the documentation.

[Tom]

I suspect that a lot of novice programmer's code is long and complicated because they really don't understand what the statements are doing. Instead they are mimicking patterns that they have seen without fully understanding how or why they work.  That is why you so often see code with redundant steps.

The best way to learn how a language works is to play with it.  Like a toddler. Pick it up, turn if over, shake it, stick it in your mouth to see what it tastes like.  Since SAS is essentially interpreted it lends itself readily to experimenting with code. 

[Reeza]

---

@koyelghosh wrote:

• How do you coders think, when you are writing the code?

I comment my code before I write it, which means the problem is essentially solved, I'm just writing the code t the solution I've already devised. An older friend of mine learned to code on punch cards and since he had to line up to submit his code to test, you'd go over and over the logic before hand to find all the bugs and ensure it would work/compile before you hit submit. I've learned the opposite, because computers have changed. I'm a 'hacker', try, test and repeat. I also did, intentionally, take a course on computer fundamentals and logic. The computer fundamentals, covered things like loops and algorithms that helped. The other course, a mathematical gaming/proof course taught me how to prove/disprove things and logic theory that has proven quite useful in life and programming. 

What makes you write much compact codes?

Laziness, less code = less typing & less to maintain

How do you coders see, (as put, in the movie Imitation Games, by Alan Turing), wrong/unnecessary connections in code and weed them out?

Experience primarily, I've made all the mistakes so its easy to spot them now

Why as a beginner, I fail to see compactness at times and tend to write longer codes?

Experience, it'll come with time, but you literally don't even know what you don't know. The experience curve is a cliche for a reason. 

---

---

---

[Cynthia_sas]

Ha, ha, love the graph. But instead of "Mount Stupid" I prefer to think of it as the Hierarchy of Competence -- instead of a curve -- https://en.wikipedia.org/wiki/Four_stages_of_competence 

Cynthia

[SASKiwi]

@koyelghosh - congratulations on a great post, and to all those responding too.

I'd just like to point out that there are no "right" or "wrong" ways to write SAS code as long as you get the right answers - just better ways. With experience SAS programmers figure out the most effective, efficient and readable coding solutions. Don't forget that they develop their own way of approaching certain problems which results in their own coding style which is perfectly OK.

[ballardw]

I find that I can't write a program to do something I personally can't do. The instructions I am writing in a program are translating my knowledge or in some cases familiarity with an issue into a more formalized instruction.

I actually think that compact, readable and "elegant" code often are somewhat in conflict. Some of the most compact or elegant solutions can be very difficult to understand when they start using obscure bits of number theory or nesting functions 8 levels deep to avoid adding a single temporary variable.

One thing that I have pointed out is that programming language documentation is actually helpful. The main problem is that you need a certain level of experience to recognize or use it. I suggest that after working with a language for a while that you read or skim sections of documentation related to what you have been working on. That may let you recognize an approach that you hadn't realized would be useful in your project.

[koyelghosh]

Thank you everybody who took out time from their lives and responded (from the bottom of my heart). I have been reading this thread since I posted it and have gone through iterations of all the posts. So much to learn from every post. If I praise each one of you, this post will become very long. All these suggestions will keep coming back to me every now and then. Hopefully different suggestions will help me at a different times. Thank you again.

and now I have to close this thread and accept one of the posts as solution. I don't have the ability or qualifications to do so, at this moment. Wisdom is speaking through every post. Still, I have to close this thread. So I decided to roll "kind of" 8 sided dice (since 8 members responded to my post) .. 10000 times for each member and counted how many times it landed in favour of each member. In the end I sorted it... and I did not change the random seed (1234567) after typing it once. 

The code is as below.

DATA Names;
	LENGTH UserNames $15;
	INPUT UserNames $;
	DATALINES;
KurtBremser
Cynthia_SAS
PaigeMiller
Astounding
Tom
Reeza
SASKiwi
ballardw
;
RUN;

%LET ProbabThresholdAccept = 0.95;
DATA MaxOf_10000_Trials(DROP=I);
	CALL STREAMINIT(1234567);
	SET Names;
	Score = 0;
	DO I=1 TO 10000;
		IF RAND('Uniform') > &ProbabThresholdAccept THEN Score + 1;
	END;	
	OUTPUT;
RUN;

PROC SORT DATA=MaxOf_10000_Trials OUT=SortedData;
	BY DESCENDING Score ;
RUN;

PROC PRINT DATA=SortedData;
RUN;

Sorted Table

So thank you @Kurt_Bremser and thank you everybody.

[Kurt_Bremser]

You're having fun, so you satisfy one of my conditions for having "it" 🙂