Presentation: 11/02/2014 @ 07:30AM
Perfion · Niels Jernes Vej 8 · DK-9220 Aalborg · Denmark
Tlf Michael Coxeter 31 14 38 84
How big should a function be? 20 Lines? A screenful? Is there a way to know if your functions are the right size?
Object Oriented Design involves the art of breaking applications into classes. But have you found all the classes in the design of your application? Is there a way to know?
Functions are supposed to do "One Thing", do it well, and do it only. But what is "One Thing". Is there a way to tell if your functions are obeying that rule?
The answer to all these questions is yes! And not just with some fuzzy hand-waving platitudes either. There are fool-proof and unambiguous answers to these questions.
In this episode Uncle Bob (UB) shows you, in no uncertain terms, how to tell if your functions are the right size. He'll show you how to be certain that you've found all the classes in your design. He'll show you where they go to hide, and how to dig them out. And he'll show you what "One Thing" really means, and how to make sure your functions are doing one and only one thing.
This episode is loaded with code; but it's no screencast! Oh you'll see some screencasts, but not in the ordinary way -- not hardly. UB controls these screencasts -- he controls the audio, the video, the speed, and the magnification. He narrates and summarizes and points out the highlights. You'll see what you need to see, without waiting for the typing. In fact, UB compresses two hours of screencasts into three sessions totalling about twenty minutes. So it's a wild ride.
On that ride you'll learn why function size is so important to Object Oriented Design, and also just to plain old good programming. You'll learn the craftsman's way of writing and refactoring functions.
Improve your coding skills and have fun. Learn by doing, and meet other driven students. We participate in a number of activities which include code katas, refactoring, view professional presentations etc. Most of the code katas are undertaken using c#, .net but any programming paradigm is appropriate. We meet every Tuesday at 7.30am at Perfion, Niels Jernes Vej 8, 9220 Aalborg. If you would like to participate, send an email to the blog for details.
Showing posts with label Craftsmenship. Show all posts
Showing posts with label Craftsmenship. Show all posts
Monday, February 10, 2014
Monday, January 27, 2014
Clean Code → Names++
Presentation: 28/01/2014 @ 07:30AM
Perfion ∙ Niels Jernes Vej 8 ∙ DK-9220 Aalborg ∙ Denmark
Tlf Michael Coxeter 31 14 38 84
Despite the scenery, Uncle Bob never lets up on driving each point home so they become part of your daily discipline.
He begins with the exhortation that names are not just a convenience for the programmer. They are the most powerful tool that programmers have to communicate with each other.
Then he dives into a discussion on how to use names to Reveal Your Intent and Avoid Disinformation.
From one code example to the next (showing up in the most unlikely places) you'll see Uncle Bob point out examples of bad names and good names. He'll explain why the good names are good, why the bad names are bad, and how to improve them.
Uncle Bob will tell you how encoding schemes like Hungarian Notation began, and why youdon't want to be using them in the twenty-first century. He'll go on to stress the importance of choosing names that make your code read like well written prose.
Finally, Uncle Bob will tell you about The Scope Rule which will guide you in choosing function, class, and variable names of the appropriate length for the scope that contains them.
Perfion ∙ Niels Jernes Vej 8 ∙ DK-9220 Aalborg ∙ Denmark
Tlf Michael Coxeter 31 14 38 84
Despite the scenery, Uncle Bob never lets up on driving each point home so they become part of your daily discipline.
He begins with the exhortation that names are not just a convenience for the programmer. They are the most powerful tool that programmers have to communicate with each other.
Then he dives into a discussion on how to use names to Reveal Your Intent and Avoid Disinformation.
From one code example to the next (showing up in the most unlikely places) you'll see Uncle Bob point out examples of bad names and good names. He'll explain why the good names are good, why the bad names are bad, and how to improve them.
Uncle Bob will tell you how encoding schemes like Hungarian Notation began, and why youdon't want to be using them in the twenty-first century. He'll go on to stress the importance of choosing names that make your code read like well written prose.
Finally, Uncle Bob will tell you about The Scope Rule which will guide you in choosing function, class, and variable names of the appropriate length for the scope that contains them.
Thursday, January 2, 2014
Better Software — No Matter What
Presentation: 02/01/2014 @ 07:30AM
Some development practices improve software quality, regardless of the domain of the application, the language in which it's written, the platform on which it runs, or the users it is intended to serve.
This seminar explores fundamental principles, practices, and standards that improve software quality, no matter what the software does, how it does it, or whom it does it for.
Video
Scott Meyers: Better Software — No Matter What
This seminar explores fundamental principles, practices, and standards that improve software quality, no matter what the software does, how it does it, or whom it does it for.
Video
Labels:
Craftsmenship
Location:
Niels Jernes Vej, 9220 Aalborg, Denmark
Subscribe to:
Posts (Atom)