1 / 26

TAGD

10/19/11. TAGD. Schedule. Announcements TWIG Replay Writing Readable Code. Announcement. TWIG. Replay. Writing Readable Code. When writing code, correctness is obviously most important. However, making it readable might be second most important. Why?. Writing Readable Code 2.

aminia
Télécharger la présentation

TAGD

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 10/19/11 TAGD

  2. Schedule • Announcements • TWIG • Replay • Writing Readable Code

  3. Announcement

  4. TWIG

  5. Replay

  6. Writing Readable Code • When writing code, correctness is obviously most important. • However, making it readable might be second most important. • Why?

  7. Writing Readable Code 2 • Because one of the main jobs for programmers is maintaining code. • Adding new features • Bug fixing • Etc. • If you don’t write clean code, you will make the above tasks hard. • You will someday forget why you wrote your code the way you did!

  8. “Correct” Code #include <iostream> using namespace std; #define tetmp= //OMDHAF int main(){ char tmp; for(inti=0;i<4;i++){te i%2==0?te 'e':te 'i';cout<<tmp;} cout<<'o'; }

  9. “Correct” Code • Can you tell what that code does? • Possibly, but it’s certainly not easy. • We can definitely do better.

  10. Indentation & Spacing • The compiler can read our code just based upon the syntax. • Technically, we don’t need to space code at all. • Humans can’t read it that way. • Proper spacing is key. • Each statement on one line. • Indent each code block outwards. • Space out statements.

  11. Better Code #define tetmp= //OMDHAF int main() { char tmp; for(intI = 0; I < 4; i++) { teI % 2 == 0 ? te 'e‘ : te 'i'; cout << tmp; } cout << 'o'; }

  12. Defines • Defines are a powerful tool for simplifying how code looks. • But it can also make it harder to read. • How it works: • #define name statement • Now, every time you put the name down, the compiler will turn it into the statement.

  13. Defines part Deux • How can we use it? • Cover up namespaces • #define STRING std::string • Give names to weird constants • #define PI 3.14159 • …as well as even more advanced stuff! • However, use defines sparingly • Try to use c++ constructs instead when possible • e.g. using and const

  14. Even Better Code #define IS_EVEN % 2 == 0 //OMDHAF int main() { char tmp; for(inti = 0; i < 4; i++) { tmp = i IS_EVEN ? tmp = 'e‘ : tmp = 'i'; cout << tmp; } cout << 'o'; }

  15. Operators • You may notice that there’s an odd statement in the middle of the code. • What is it? • A special operator called the conditional. • Conditional operator • Condition ? True_result : False_result • This is basically shorthand for the if statement you are used to.

  16. More Operators • There are 18 classes of operators in C++. • Basic: +, - • Bitwise: &, | • Pointers: ., & • Etc. • It’s a good idea to know all of them. • However, use the odd ones only when necessary. • For example, avoid the conditional for readability.

  17. Even More Better Code #define IS_EVEN % 2 == 0 //OMDHAF int main() { char tmp; for(inti = 0; i < 4; i++) { if(I IS_EVEN) tmp= 'e‘ else tmp= 'i'; cout << tmp; } cout << 'o'; }

  18. Naming • Variable names are an important part of code. • Helps us know what a variable represents. • Choose long, useful names • 8-24 characters is a good length • Name it based on what is stored inside. • User_name, account_number

  19. More about Naming • Don’t name variables “temp” or “tmp” • All variables are temporary • If your variables aren’t, that means that they will be around after your program ends. • This is called a memory leak = bad! • It’s OK to use i, j, k for loops • Established mathematical convention • If you have a better name though, use it.

  20. Yet Even More Better Code #define IS_EVEN % 2 == 0 //OMDHAF int main() { char chorus; for(inti = 0; i < 4; i++) { if(I IS_EVEN) chorus = 'e‘ else chorus = 'i'; cout << tmp; } cout << 'o'; }

  21. Commenting • Even though we can read what our code does now, there’s still a problem. • Why does it do that? • If we had commented it, we’d know. • Comments allow us to leave notes behind. • To both others and ourselves to read. • Can help us remember why we did what we did.

  22. Comments on Commenting • Some good comments to leave include: • On functions: summary, arguments, returns • On classes: summary, data members, member functions • Also good for marking places to come back to later. • Don’t leave comments that don’t help with code readability!

  23. Bestest Code #define IS_EVEN % 2 == 0 //This prints the chorus to “Old McDonald” int main() { char chorus; for(inti = 0; i < 4; i++) { if(I IS_EVEN) chorus = 'e‘ else chorus = 'i'; cout << tmp; } cout << 'o'; }

  24. Code output • If you’re curious, that code we cleaned up prints: • “eieio”

  25. Obfuscation • Sometimes, you might actually want to make code hard to read. • Protect parts of source code. • Annoy your friends! • If you do, just do the opposite of everything I’ve said here. • But you should feel bad doing it.

  26. Homework • Take a really old piece of code you have written and clean it up. • You will also see how hard it is to remember what your code was for. • Send me speaking topics! • Otherwise, I’ll do another boring one like this.

More Related