Presentation: 10/03/2014 @ 07:30AM
Perfion · Niels Jernes Vej 8 · DK-9220 Aalborg · Denmark
Presentation
What is a responsible programmer? What habits does a responsible programmer
have? I started asking myself and others that question and this presentation is
the result of this. I will look into good habits for coding, using tools,
managing environments and working in projects. Example of good habits are:
Merciless refactoring! No quick-fixes! Script everything! and Don't do as your
told!
Showing posts with label CleanCode. Show all posts
Showing posts with label CleanCode. Show all posts
Monday, March 10, 2014
Monday, February 10, 2014
Prime Numbers Refactoring
Presentation: 18/02/2014 @ 07:30AM
Perfion · Niels Jernes Vej 8 · DK-9220 Aalborg · Denmark
Tlf Michael Coxeter 31 14 38 84
In this session we will look at re-factoring some code that produces and outputs prime numbers.
There will be focus on finding buried the classes hidden with the the functions and extracting them as first class citizens.
This re-factoring will attempt to result in a number of small well named classes filled with small well named functions, as was described in the previous presentation
Clean Code → Functions
Perfion · Niels Jernes Vej 8 · DK-9220 Aalborg · Denmark
Tlf Michael Coxeter 31 14 38 84
In this session we will look at re-factoring some code that produces and outputs prime numbers.
There will be focus on finding buried the classes hidden with the the functions and extracting them as first class citizens.
This re-factoring will attempt to result in a number of small well named classes filled with small well named functions, as was described in the previous presentation
Clean Code → Functions
Clean Code → Functions
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.
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.
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.
Subscribe to:
Posts (Atom)