Additionally to other answers, there can be actual ways to feel about code. By feel, I mean instinctively interact with code.
First, the formatting of the code itself can be easier for people to read and understand using some basic principles that help us read the code. Gestalt Principles can help anything be more quickly and easily understood by humans (applied heavily in data visualization). Using these principles for simple things like aligning comments, placing spaces and blank lines in the right place all help people read code more easily at an instinctive level.
A lot of my coding conventions and formatting is based on making it easier to read first at a subconscious level.
Which feels more readable?
int x; //This is an x
string foo; //Foo here
MyObject baz; //Instance of MyObject
int x; //This is an x
string foo; //Foo here
MyObject baz; //Instance of MyObject
EDIT
To Michael's comment about having a long declaration. Our minds are forgiving, so the laws don't have to be followed exactly.
int x; //This is an x
string foo; //Foo here
MyObject baz; //Instance of MyObject
MyTypeWithSomeAwfullyLongName bar;
long UUID; //The Law can be broken and still help
The Law of Proximity should mean most people like the second version better. It's the same reason we have columns and tables to organize data.
Another example, based on the Law of Symmetry
function fooBarLongMethodName() {
return null;
}
function fooBarLongMethodName()
{
return null;
}
The law of symmetry states that the mind perceives objects as being
symmetrical and forming around a center point. It is perceptually
pleasing to divide objects into an even number of symmetrical parts.
So it is more pleasing for the mind to see the symmetry in the second example, being able to see both the open and close braces in line.
These examples should instinctively make reading code easier. But there are also learned patterns that it takes time for you to take advantage of, these are based on the Law of Past Experience.
So secondly, understanding the intent of certain code, and knowing when it's being used incorrectly (especially without having to investigate or know much about previous code). This article talks about naming variables so that you can see from the names when they're are being used incorrectly. Once this pattern of naming and use have become habitual, it's possible to recognize an issue with the code by site and without having to investigate much of the other code.
Finally, these lead into a larger idea of Code Smells. The idea that certain patterns that emerge in code can commonly signal an issue somewhere in the code. This sometimes shows up as a sentiment "This unit testing code is ugly, why is it even necessary?" and the answer to that question is maybe "Oh, you're using Singletons for everything.". This is the hardest to teach or learn and probably only comes with experience.
So I hope this helps expand on the other answers as to why or how people can consider code 'beautiful', 'good', or 'ugly'
