unlucky coding

[lmal]

Some work I've been doing at college, im working really hard to become a programmer :D

Can you tell me how could i make this code better? Im trying to improve my coding style ^^

Thank you for answering!! Gonna try apply those tips and will post code corrected!

[48T7M4Gy]

Here's one place you could get some sound advice on style.
https://google.github.io/styleguide/cppguide.html

A couple of observations that might help you also:
1. Take advantage of whitespace, even within a line. a = b is easier to read than a=b
2. single character variable names are bad - they lead to errors, are not easy to track and render the code almost unreadable except to the programmer. Good names lead to self-documenting code.
3. Capitalised names like Autovectores are better as autovectores - saves time and caps changes and generally only apply to class names
4. trigonometrical transfom equations are obscured by the same problem with variable names CO, SI would be better as cos, sin
e.g.

if (C<0){ T=-C-sqrtl(1.+C*C);}
    else{ T=-C+sqrtl(1.+C*C); }
    CO=1./sqrtl(1.+T*T);

reads much better, and is easier to check as:

if ( cos < 0 )
   tan = -cos- sqrtl( 1. + cos * cos);
else
   tan = -cos + sqrtl( 1. + cos * cos);

cos = 1. / sqrtl( 1. + tan *  tan);

I'm guessing that T = tan etc, but you get the idea about whitespace and variable names I hope.

Cramming up everything and having multiple lines on a single line is considered by some programmers to be sophisticated and stylish. The reality is it is bad programming because it makes the code difficult to understand, test, debug and maintain. :)

[YFGHNG]

Think of writing code as if you were writing a college essay. Your professor wants that 12 pt Times New Roman font for a reason. There's a certain structure that should be followed in terms of logical consistency and in terms of physical writing. You don't want to start talking about global warming and suddenly mention halfway through that your topic is about starving children in Zimbabwe or something.

Don't be afraid of spacing everything out. It won't take significantly longer to compile just because you wrote for( int x = 0; x < a; ++x ) vs for(int x=0;x<a;++x)

https://en.wikipedia.org/wiki/Naming_convention_(programming)

In the wiki above, there's several common naming conventions that most programming languages and most programmers share.

And as @kemort mentioned, white spaces do come in handy lots of times. If you're writing a for loop and the conditions are kind of long, just separate with an Enter. They'll still compile perfectly fine. The only exception I can think of when it comes to that is when you std::cout a string literal, and without an end quotation, things get funky if you try to separate them on multiple lines without use of operator<< or a semicolon.

[JayhawkZombie]

If I may add something.

Readability is much more important than trimming lines of code. Self-documenting code is wonderful. There is some code that I just will not read if it is very poorly formatted or the variable names are too cryptic (I'm looking at my father here).

int p; is not good.

int positionOfSomething; is good. It describes exactly what it is for right in the name of the variable.

void f(); is not good.

void setValueOfSomething(<args>); is good. It describes what the function is doing right in the name. That is self-documenting code, and programmers love it.

It is OK to have long variable and function names (but don't get crazy with it). I'd rather have a long variable name than a short one.

Most IDEs will pull comments from header/implementation files and display them to someone using your code as they are typing. Document your headers and implementations so that someone who is using it can see descriptions of what everything does

I have a large piece of software that I am building to show off my skills. It's now thousands of lines of code long. Could you imagine trying to decode that or read it if it was poorly formatted or the variables/functions were cryptic? It would be a nightmare.
Separate things with classes, and sometimes namespaces. That can make it even more clear exactly what the code that you wrote is doing.

Please don't shove everything onto one line. Your code looks much more sophisticated when it is nicely formatted and spread out. And for someone like me who suffers from ADHD, it is actually extremely difficult to focus on something that is cluttered. Seeing code spread out with white space and documentation makes it much more readable.

Try to stick with conventions as much as you can. It'll make things easier for others when they read it.

The two comments above me give great advice. Coding is fun, but make sure that it's fun for others to read your code.

[48T7M4Gy]

Yep, going to the other extreme:

you_can_have_really_Impossibly_long_names
or
youCanHaveReallyImpossiblyLongNames regardless of the naming style convention too.

They are all legal, but get in the way of readability.

One of the big challenges is to come up with a good name. The classic example of a less than adequate name is calling an int array[5] = ...; 'array', the [] is sort of a giveaway and leaves open the opportunity to be more expressive. ( int variable = 0; is another one)
:)

[JayhawkZombie]

Exactly. Stay away from both extremes.

Here is a method name from the Cocoa framework. 62 characters.

NSAccessibilityLayoutPointForScreenPointParameterizedAttribute

It is very descriptive, but excessively long - almost unreadable. Keep them short and to the point. Using abbreviations is fine, just make sure they are obvious what they are short for.

[YFGHNG]

@OP you don't have to edit out your code. It's not like the Cheat Police are gonna raid your house and bust a cap.

Having your unedited code present along with the comments below gives other, newer people who stumble upon this post a chance to compare the good and the bad. Don't be selfish because you don't want other people to see your stuff.