I really enjoyed reading The Art of Readable Code. I always enjoy reading books on style, both English writing as well as source code. The earlier chapters were a greater highlight to me, as they focused on the basics of style and particularly were demonstrated through languages with which I am familiar. Some of the later chapters instead were examples particular to languages that I do not use, such as illustrating style pitfalls with JavaScript. The book also had value in showing several approaches and continuing to refactor the code to better meet style and readability.
While the topic is style, this is really more about fundamentally good practices, which may be implemented in one of several ways (e.g., where to put braces, camel case, etc) that is termed style. Between this and the examples within the text, I want to start requiring it of students. I want them to read and see why style actually matters. Or maybe we will just have to wait until they experience why it matters and suffer for it.
Showing posts with label style. Show all posts
Showing posts with label style. Show all posts
Thursday, December 29, 2016
Friday, April 17, 2015
Repost: Code Quality
xkcd had a great comic today about the code quality of self-taught programmers. While there are technically trained programmers that write poor quality code, my impression is that this is more common with self-taught programmers as well as programmers who are only taught programming itself. Basically as part of the technical training, someone learns more than just programming. They learn about CS theory, data structures, multiple programming languages, and are more often exposed to well written / designed programs. Learning to program at a high quality is similar to learning a natural language, in that you study grammar and spelling, you read great works of literature and analyze them, and you practice reading / writing / speaking.
Each month I understand better what it takes to be competent in my field and also respect more the idea that curriculum is established by experts for a purpose, whether or not I may like certain topics.
Each month I understand better what it takes to be competent in my field and also respect more the idea that curriculum is established by experts for a purpose, whether or not I may like certain topics.
Tuesday, March 10, 2015
Book Review: Geek Sublime: The Beauty of Code, the Code of Beauty
A book of such promise is Geek Sublime: The Beauty of Code, the Code of Beauty, yet it fails. The first third of this work followed the hopeful theme, intertwining the story of programming, its style, and the author's complex relationship with his Indian heritage, desire to be an artist (writer, etc), and his ability to make money programming. An interesting twining that continued to encourage me to read, yet some worrisome signs developed.
The first worry was skipping a long section on how computers work. This *is* my field of Computer Science, so I wasn't interested in reading the basics. Yet worse was noticing some inaccuracies. They established a certain level of understanding in Computer Science that was concerning, particularly in light of the author's non-technical background. Livable, er readable, sure.
It was then the author's intent to show the great intellectual contributions made by Indians. I have no dispute of this point, except that it wasn't actually fitting with the established theme of the work. Finding that Sanskrit has a codified language of great antiquity enabled the author in this quest. Alas, it was long pages that grew increasingly divorced with the first part of the title, "The Beauty of Code" and further focus on the later, "The Code of Beauty". And this code deriving from Indian literary traditions.
In the end, the book concluded. A crescendo of final claims that each read like next page would be the last, until such time as there was really no text left. I learned something about Indian culture by reading this book, except that was not why I read it. I did not gain in what I sought, so I cannot recommend reading it, nor care to provide a link to it.
The first worry was skipping a long section on how computers work. This *is* my field of Computer Science, so I wasn't interested in reading the basics. Yet worse was noticing some inaccuracies. They established a certain level of understanding in Computer Science that was concerning, particularly in light of the author's non-technical background. Livable, er readable, sure.
It was then the author's intent to show the great intellectual contributions made by Indians. I have no dispute of this point, except that it wasn't actually fitting with the established theme of the work. Finding that Sanskrit has a codified language of great antiquity enabled the author in this quest. Alas, it was long pages that grew increasingly divorced with the first part of the title, "The Beauty of Code" and further focus on the later, "The Code of Beauty". And this code deriving from Indian literary traditions.
In the end, the book concluded. A crescendo of final claims that each read like next page would be the last, until such time as there was really no text left. I learned something about Indian culture by reading this book, except that was not why I read it. I did not gain in what I sought, so I cannot recommend reading it, nor care to provide a link to it.
Monday, July 14, 2014
Book Review: The Practice of Programming
(contains Amazon affiliate link)
I recently found, The Practice of Programming (Addison-Wesley Professional Computing Series), sitting on the shelf at my local library. I am generally skeptical when it comes to programming books, and particularly those from different decades, but I trusted the name "Brian Kernighan" so I checked the book out.
And I am so glad that I did. From the first chapter that discussed style, I wanted to read more. And the only reason to ever stop reading was to pull out a computer and put these things into practice. I didn't even mind that it wasn't until chapter 7 that performance was discussed. Still, I will readily acknowledge that I disagree with some of statements in the book. Furthermore, there are some parts of the text that are clearly dated, like discussing current C / C++ standards.
I'd like to conclude with a brief code snippet from the work. This code is part of a serializer / deserializer. Such routines are always a pain to write and particularly if you have many different classes / structs that need them. Thus the authors suggest using vargs and writing a single routine that can handle this for you. Here is the unpack (i.e., deserialize) routine:
/* unpack: unpack packed items from buf, return length */
int unpack(uchar *buf, char *fmt, ...)
{
va_list args;
char *p;
uchar *bp, *pc;
ushort *ps;
ulong *pl;
bp = buf;
va_start(args, fmt);
for (p = fmt; *p != '\0'; p++) {
switch (*p) {
case 'c': /* char */
pc = va_arg(args, uchar*);
*pc = *bp++;
break;
case 's': /* short */
ps = va_arg(args, ushort*);
*ps = *bp++ << 8;
*ps |= *bp++;
break;
case 'l': /* long */
pl = va_arg(args, ulong*);
*pl = *bp++ << 24;
*pl |= *bp++ << 16;
*pl |= *bp++ << 8;
*pl |= *bp++;
default: /* illegal type character */
va_end(args);
return -1;
}
}
va_end(args);
return bp - buf;
}
So now we have a little language for describing the format of the data in the buffer. We invoke unpack with a string like "cscl" and pointers to store the char, short, char and long. Hah! That's it. Anytime we add new types, we just to call the pack / unpack.
Does it matter that the variables are only sequences like "pl" or "bp"? No. Variable names should be meaningful and consistent. "i" can be fine for a loop iterator.
We have given up some performance (*gasp*), but gained in the other parts that matter like readability and maintainability. I plan on using this in my current research (but only the unpack, as my serializers are already highly optimized). All in all, I approve of this book and may even someday require it as a textbook for students.
I recently found, The Practice of Programming (Addison-Wesley Professional Computing Series), sitting on the shelf at my local library. I am generally skeptical when it comes to programming books, and particularly those from different decades, but I trusted the name "Brian Kernighan" so I checked the book out.
And I am so glad that I did. From the first chapter that discussed style, I wanted to read more. And the only reason to ever stop reading was to pull out a computer and put these things into practice. I didn't even mind that it wasn't until chapter 7 that performance was discussed. Still, I will readily acknowledge that I disagree with some of statements in the book. Furthermore, there are some parts of the text that are clearly dated, like discussing current C / C++ standards.
I'd like to conclude with a brief code snippet from the work. This code is part of a serializer / deserializer. Such routines are always a pain to write and particularly if you have many different classes / structs that need them. Thus the authors suggest using vargs and writing a single routine that can handle this for you. Here is the unpack (i.e., deserialize) routine:
/* unpack: unpack packed items from buf, return length */
int unpack(uchar *buf, char *fmt, ...)
{
va_list args;
char *p;
uchar *bp, *pc;
ushort *ps;
ulong *pl;
bp = buf;
va_start(args, fmt);
for (p = fmt; *p != '\0'; p++) {
switch (*p) {
case 'c': /* char */
pc = va_arg(args, uchar*);
*pc = *bp++;
break;
case 's': /* short */
ps = va_arg(args, ushort*);
*ps = *bp++ << 8;
*ps |= *bp++;
break;
case 'l': /* long */
pl = va_arg(args, ulong*);
*pl = *bp++ << 24;
*pl |= *bp++ << 16;
*pl |= *bp++ << 8;
*pl |= *bp++;
default: /* illegal type character */
va_end(args);
return -1;
}
}
va_end(args);
return bp - buf;
}
So now we have a little language for describing the format of the data in the buffer. We invoke unpack with a string like "cscl" and pointers to store the char, short, char and long. Hah! That's it. Anytime we add new types, we just to call the pack / unpack.
Does it matter that the variables are only sequences like "pl" or "bp"? No. Variable names should be meaningful and consistent. "i" can be fine for a loop iterator.
We have given up some performance (*gasp*), but gained in the other parts that matter like readability and maintainability. I plan on using this in my current research (but only the unpack, as my serializers are already highly optimized). All in all, I approve of this book and may even someday require it as a textbook for students.
Monday, March 3, 2014
Ongoing Goto Wars
Recently, Apple announced a security fix for their SSL implementation. I would have taken little note here, except WIRED's summary indicated the cause being the use of goto. Ah, goto, how useful you are. How abused you are.
In practice, I would also have used goto, if I was writing a series of conditionals where I only have a single error block. The code could be restructured to link all of the conditionals into a single clause, yet it also tries to retain the specific error code for the check that failed. I would really dislike to see the following:
Leave me to shrug. I'll use my goto, sparingly. And I'll continue to try to impress on students that they and all of us programmers will make mistakes so write elegant code to help find these bugs. Until then, if anyone has a good construction for the error code that doesn't require goto, let me know.
In practice, I would also have used goto, if I was writing a series of conditionals where I only have a single error block. The code could be restructured to link all of the conditionals into a single clause, yet it also tries to retain the specific error code for the check that failed. I would really dislike to see the following:
if ((e = foo) != 0 && (e = bar) != 0 && ...) goto fail;So what then? Do we call upon the software engineering folk to better analyze programs and find these mistakes? Or write style guidelines that require braces for every if, and ban every goto? And then the employee's manager is required to sign off on every exception. These are some of the many proposals floated for addressing this, and often made by programmers touting the superiority of their proposal and how this would never happen to them.
Leave me to shrug. I'll use my goto, sparingly. And I'll continue to try to impress on students that they and all of us programmers will make mistakes so write elegant code to help find these bugs. Until then, if anyone has a good construction for the error code that doesn't require goto, let me know.
Wednesday, July 24, 2013
Repost: There's nothing like a tidy codebase
When I grade student assignments, around 90% of the grade is for what the code does. The other 10% is for how it looks, because There's nothing like a tidy codebase. So take some additional time and help ensure that the code you write is readable.
Thursday, July 11, 2013
Book Review: Exceptional C++ Style 40 New Engineering Puzzles, ...
Generally, I do not write code in C++; however, on occasion (like when writing LLVM compiler passes), I am forced into using this language. I also more regularly find myself grading student assignments that have used C++. Particularly reading these assignments, I will be thankful to have read this book and better be able to express how students have violated the standards, as they have done in the past.
Were I forced to read a book directly on the C++ standards, let's just say I can think of lots of things I'd rather be doing. But while Exceptional C++ Style: 40 New Engineering Puzzles, Programming Problems, and Solutions exposed me to more of the standards, I never felt like I was reading quotes from the standard. Instead, I was listening to an interesting conversation about some real programming questions that just may require invoking the standards to answer.
I enjoyed chapters 20 and 21, as I appreciate the effort toward explaining how memory is allocated and structures laid out. Help dispel the ignorance that new / malloc are how the OS provides memory. And I then learned that new will throw an exception instead of returning NULL. Perhaps time to rewrite some code. Furthermore, I understand now why most C++ code uses preincrement on iterators.
It is not strictly a book on style, but instead this tome covers the style I care most about: good programming practices. I don't care which style convention you use, so long as you use one consistently. But for whatever style your code has, it had better be good code.
I recommend reading this book even if you do not regularly use C++. I will note that it is dated; however, unless you are now using C++11, the text is still timely and even if you are using C++11 I doubt that everything has changed (though I did notice the discussion of the auto keyword was out of date).
Were I forced to read a book directly on the C++ standards, let's just say I can think of lots of things I'd rather be doing. But while Exceptional C++ Style: 40 New Engineering Puzzles, Programming Problems, and Solutions exposed me to more of the standards, I never felt like I was reading quotes from the standard. Instead, I was listening to an interesting conversation about some real programming questions that just may require invoking the standards to answer.
I enjoyed chapters 20 and 21, as I appreciate the effort toward explaining how memory is allocated and structures laid out. Help dispel the ignorance that new / malloc are how the OS provides memory. And I then learned that new will throw an exception instead of returning NULL. Perhaps time to rewrite some code. Furthermore, I understand now why most C++ code uses preincrement on iterators.
It is not strictly a book on style, but instead this tome covers the style I care most about: good programming practices. I don't care which style convention you use, so long as you use one consistently. But for whatever style your code has, it had better be good code.
I recommend reading this book even if you do not regularly use C++. I will note that it is dated; however, unless you are now using C++11, the text is still timely and even if you are using C++11 I doubt that everything has changed (though I did notice the discussion of the auto keyword was out of date).
Subscribe to:
Posts (Atom)