This document provides a summary of a presentation on object-oriented programming (OOP) and clean code given at IPB Computer Science on March 28, 2017. It introduces the speaker, Ifnu Bima, and his background working at Deutsche Bank and blibli.com. The presentation covers topics like code quality metrics, meaningful naming conventions, high-quality functions, comments, and unit testing. It emphasizes writing code that is easy to maintain and modify over time to prevent issues like bugs and technical debt.
A summary of clean code concepts and tips along with some examples and good practices.
These are the slides translated in English from my talk on Clean Code to my coworkers back then
Presentación para la charla sobre el libro de Robert C. Martin, Clean Code.
Esta presentación la impartí en CyLicon Valley, aquí tenéis el video con el audio de la charla => https://www.youtube.com/watch?v=1Fss1jBfc3g
All 3 Clean Code presentations provide great value by themselves, but taken together are designed to offer a holistic approach to successful software creation. This first session creates the foundation for the 2nd and 3rd Clean Code presentation on Dependency Injection, as it explains expected base knowledge. Why writing Clean Code makes us more efficient Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs.
Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code. You will be presented design patterns and best practices which will make you write better and more easily maintainable code, seeing code in a holistic way.
You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained. This presentation is based on C# and Visual Studio 2012. However, the demonstrated patterns and practice can be applied to every other programming language too.
Note: Moving forwards this presentation will be updated with the latest version of the slides for the last event I did the presentation instead of creating new separate slide decks here on SlideShare.
Presentation dates and locations:
2015-10-03 Silicon Valley Code Camp, San Jose, CA
2015-06-27 SoCal Code Camp - San Diego, CA
2014-11-14 SoCal Code Camp - Los Angeles, CA
2014-10-18 Desert Code Camp - Chandler, AZ
2014-10-11 Silicon Valley Code Camp, Los Altos Hills, CA
A summary of clean code concepts and tips along with some examples and good practices.
These are the slides translated in English from my talk on Clean Code to my coworkers back then
Presentación para la charla sobre el libro de Robert C. Martin, Clean Code.
Esta presentación la impartí en CyLicon Valley, aquí tenéis el video con el audio de la charla => https://www.youtube.com/watch?v=1Fss1jBfc3g
All 3 Clean Code presentations provide great value by themselves, but taken together are designed to offer a holistic approach to successful software creation. This first session creates the foundation for the 2nd and 3rd Clean Code presentation on Dependency Injection, as it explains expected base knowledge. Why writing Clean Code makes us more efficient Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs.
Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code. You will be presented design patterns and best practices which will make you write better and more easily maintainable code, seeing code in a holistic way.
You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained. This presentation is based on C# and Visual Studio 2012. However, the demonstrated patterns and practice can be applied to every other programming language too.
Note: Moving forwards this presentation will be updated with the latest version of the slides for the last event I did the presentation instead of creating new separate slide decks here on SlideShare.
Presentation dates and locations:
2015-10-03 Silicon Valley Code Camp, San Jose, CA
2015-06-27 SoCal Code Camp - San Diego, CA
2014-11-14 SoCal Code Camp - Los Angeles, CA
2014-10-18 Desert Code Camp - Chandler, AZ
2014-10-11 Silicon Valley Code Camp, Los Altos Hills, CA
Vladimir Romanov - How to write code that is easy to read and change? What should you do when you see a piece of code written years ago which is hard to understand? In my experience, this boils down to 4 principles that I would like to share along with some examples in Apex
How should a professional software developer behave in code? What guidelines should one follow? How should we name our constructs? What about OOP principles? What's their real use?
This classic training module in my training curricula is the cornerstone of my professionalism. These are my conduit guidelines at work. I've held this training > 10 times, including at Voxxed Days Bucharest 2016 and at a Bucharest Java User Group meetup.
"Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way." In this knolx session, a few important topics for having clean code are covered. Basically the following topics - Meaningful name, Functions, Comments and Classes.
The Art of Unit Testing - Towards a Testable DesignVictor Rentea
Slides of the Talk I gave at Devoxx Belgium 2019.
=== Abstract ===
Focusing on the creative work without being terrified of breaking the existing behavior can make software development very addictive! Good automated tests can buy you that!
However, if your tests are not maintainable they may end up slowing you down and causing you painful headaches, compilation errors and spurious failures. To avoid that, your unit tests should be significant; expressive; clean; DRY; non-overlapping; and blazing fast. Writing good tests becomes the toughest challenge for any developer, no matter how battle-hardened: you need to balance risk with test maintenance costs, while looking out for test design smells that call for [risky] refactoring to drive your design towards a set of key principles (included:).
Principles that will end up shaping the way you craft the Production code itself. Because in the end, a good, clean design is more important than coverage%.
But testing gives you the best feedback to get there.
Grab a black coffee and join this snippet from Victor’s Pro Unit Testing #training, to learn about testing priorities, buggy tests, the shared @Before, Mocks vs Stubs and how to reduce them by "purifying" your logic, testing Legacy Code and refactoring @Spy-es out.
All of that in an entertaining, dynamic and memorable session.
Clan code is extremely essential to build scalable application which can be maintained quite easily and improved further
Slide was prepared with contribution to my colleague
and i thank them for the help!
Presentation on writing clean and maintainable good. I have present really simple steps to write high quality code and share many more benefit of writing clean code.
Slides of the talk held at JEEConf, Kiev and jPrime, Sofia. A personal view on the classic topics from the Uncle Bob's Clean Code bible, with some personal additions and tips&tricks. This topic actually represents the core of the training sessions that I provide as an independent trainer (www.victorrentea.ro)
Clean Pragmatic Architecture - Avoiding a MonolithVictor Rentea
Talk built based on several of my trainings: http://www.victorrentea.ro/#training
Covers: Clean/Onion/Hexagonal Architecture, Domain Entities, Value Objects, Repository, Extract When it Grows Principle, Dependency Inversion Principle, Clean Code and Design Patterns.
These are the backing slides of the talks given at JPoint 2017 and Devoxx PL 2017: https://www.youtube.com/embed/4-4ahz7zDiQ
A brief overview about writing clean code. Presentation made for the Multimedia Languages and Environments course at Politecnico di Torino (academic year 2012/2013).
Rule 1: Follow a consistent coding standard
Rule 2: Name things properly, long variable and function names are allowed
Rule 3: Be expressive, write code as you speak and be optimally verbose
Rule 4: Max indent per method should be 2, in case of exceptions 3
Rule 5: Avoid creating god object and long methods
Rule 6: Keep the method in one place, inject the class and call it, DRY
Rule 7: Avoid in-line comments (comment with code), put comments in the method doc
Slides for my deep dive session at Devoxx Belgium 2019.
Main concepts:
OOP, Functional Programming, Functions, Feature Envy, Design, Refactoring, Extract Method, Signatures, side effects, pure functions, programming paradigms, emotions
Abstract:
Would you attach your last commit to your CV:
"Sample: how I write code"?
What do others think of your code?
Writing Clean Code: an old topic, but never less important, nor challenging than today!
During the first part of this deep-dive session, we will go through the essential clean code rules, learning to detect code smells, discussing refactoring ideas and alternative designs pros/cons.
Then, after the break, we will apply what we learned in a refactoring live-coding kata, explaining 10 key practical techniques you can immediately apply in your code. By the end of the session, you will have a clear picture of what clean code means and quite a variety of ways at hand to get there.
Along the way, we will also point out the differences between procedural/oop/functional paradigms and whether they are competing or complementary, speak in detail about Extract Method, statefulness, separation by layers of abstractions, OOP, and many more.
Can't wait to share my greatest passion with you: writing professional, expressive code that is a pleasure to work with.
TDD is now mainstream but a lot people don't know or don't remember what is its purpose. TDD is about software design not testing or catching bug. TDD helps developers to shape and create software with "good" design, what is a "good" design is something that we will discuss in the topic.
Vladimir Romanov - How to write code that is easy to read and change? What should you do when you see a piece of code written years ago which is hard to understand? In my experience, this boils down to 4 principles that I would like to share along with some examples in Apex
How should a professional software developer behave in code? What guidelines should one follow? How should we name our constructs? What about OOP principles? What's their real use?
This classic training module in my training curricula is the cornerstone of my professionalism. These are my conduit guidelines at work. I've held this training > 10 times, including at Voxxed Days Bucharest 2016 and at a Bucharest Java User Group meetup.
"Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way." In this knolx session, a few important topics for having clean code are covered. Basically the following topics - Meaningful name, Functions, Comments and Classes.
The Art of Unit Testing - Towards a Testable DesignVictor Rentea
Slides of the Talk I gave at Devoxx Belgium 2019.
=== Abstract ===
Focusing on the creative work without being terrified of breaking the existing behavior can make software development very addictive! Good automated tests can buy you that!
However, if your tests are not maintainable they may end up slowing you down and causing you painful headaches, compilation errors and spurious failures. To avoid that, your unit tests should be significant; expressive; clean; DRY; non-overlapping; and blazing fast. Writing good tests becomes the toughest challenge for any developer, no matter how battle-hardened: you need to balance risk with test maintenance costs, while looking out for test design smells that call for [risky] refactoring to drive your design towards a set of key principles (included:).
Principles that will end up shaping the way you craft the Production code itself. Because in the end, a good, clean design is more important than coverage%.
But testing gives you the best feedback to get there.
Grab a black coffee and join this snippet from Victor’s Pro Unit Testing #training, to learn about testing priorities, buggy tests, the shared @Before, Mocks vs Stubs and how to reduce them by "purifying" your logic, testing Legacy Code and refactoring @Spy-es out.
All of that in an entertaining, dynamic and memorable session.
Clan code is extremely essential to build scalable application which can be maintained quite easily and improved further
Slide was prepared with contribution to my colleague
and i thank them for the help!
Presentation on writing clean and maintainable good. I have present really simple steps to write high quality code and share many more benefit of writing clean code.
Slides of the talk held at JEEConf, Kiev and jPrime, Sofia. A personal view on the classic topics from the Uncle Bob's Clean Code bible, with some personal additions and tips&tricks. This topic actually represents the core of the training sessions that I provide as an independent trainer (www.victorrentea.ro)
Clean Pragmatic Architecture - Avoiding a MonolithVictor Rentea
Talk built based on several of my trainings: http://www.victorrentea.ro/#training
Covers: Clean/Onion/Hexagonal Architecture, Domain Entities, Value Objects, Repository, Extract When it Grows Principle, Dependency Inversion Principle, Clean Code and Design Patterns.
These are the backing slides of the talks given at JPoint 2017 and Devoxx PL 2017: https://www.youtube.com/embed/4-4ahz7zDiQ
A brief overview about writing clean code. Presentation made for the Multimedia Languages and Environments course at Politecnico di Torino (academic year 2012/2013).
Rule 1: Follow a consistent coding standard
Rule 2: Name things properly, long variable and function names are allowed
Rule 3: Be expressive, write code as you speak and be optimally verbose
Rule 4: Max indent per method should be 2, in case of exceptions 3
Rule 5: Avoid creating god object and long methods
Rule 6: Keep the method in one place, inject the class and call it, DRY
Rule 7: Avoid in-line comments (comment with code), put comments in the method doc
Slides for my deep dive session at Devoxx Belgium 2019.
Main concepts:
OOP, Functional Programming, Functions, Feature Envy, Design, Refactoring, Extract Method, Signatures, side effects, pure functions, programming paradigms, emotions
Abstract:
Would you attach your last commit to your CV:
"Sample: how I write code"?
What do others think of your code?
Writing Clean Code: an old topic, but never less important, nor challenging than today!
During the first part of this deep-dive session, we will go through the essential clean code rules, learning to detect code smells, discussing refactoring ideas and alternative designs pros/cons.
Then, after the break, we will apply what we learned in a refactoring live-coding kata, explaining 10 key practical techniques you can immediately apply in your code. By the end of the session, you will have a clear picture of what clean code means and quite a variety of ways at hand to get there.
Along the way, we will also point out the differences between procedural/oop/functional paradigms and whether they are competing or complementary, speak in detail about Extract Method, statefulness, separation by layers of abstractions, OOP, and many more.
Can't wait to share my greatest passion with you: writing professional, expressive code that is a pleasure to work with.
TDD is now mainstream but a lot people don't know or don't remember what is its purpose. TDD is about software design not testing or catching bug. TDD helps developers to shape and create software with "good" design, what is a "good" design is something that we will discuss in the topic.
Static analysis works for mission-critical systems, why not yours? Rogue Wave Software
Take a deep dive into the world of static code analysis (SCA) by immersing yourself into different analysis techniques, examples of the problems they find, and learning how SCA fits into various types of environments, from the developer desktop to the QA team. The goal is to provide a solid foundation for you to make the best decision for testing technology and process selection, including: Types of defects found by SCA;
Typical myths and barriers to adoption; and How SCA aligns to different testing maturity levels.
TDD is now mainstream but a lot people don't know or don't remember what is its purpose. TDD is about software design not testing or catching bug. TDD helps developers to shape and create software with "good" design, what is a "good" design is something that we will discuss in the topic.
A brief overview about how to write human readable and meaningful code. Here is described why and how to write meaningful names of variables or method, what to follow about writing a function for SRP / Open-Closed principle rule, when to write comments and rules of Code Formatting. Advantages of clean code is also described here.
Missing objects: ?. and ?? in JavaScript (BrazilJS 2018)Igalia
By Daniel Ehrenberg.
Slides at https://docs.google.com/presentation/d/1UOk7RlrCdFLs95OPQ-emm__oHD3n43zGyLsn0aGZWyI/edit#slide=id.p
JavaScript code frequently has to deal with missing values, but current mechanisms are repetitive or error-prone. Some are proposing that we change the JavaScript programming language, in a way inspired by other languages like Swift: the optional chaining and nullish coalescing operators.
We got a big upgrade to JavaScript with ES6, but TC39, the standards committee which defines the programming language, is still making improvements with this and other proposals. In this talk, I'll explain what kinds of things TC39 thinks about, how it goes about improving the programming language, and how you can participate to shape the future of JavaScript.
(c) BrazilJS 2018
24 e 25 de Agosto, Brazil
“What should I work on next?” Code metrics can help you answer that question. They can single out sections of your code that are likely to contain bugs. They can help you get a toehold on a legacy system that’s poorly covered by tests.
This is part 1 of fuzzing, an introduction to the subject. This presentation covers some of theory and thought process behind the subject, as well as an introduction to environment variable fuzzing and file format fuzzing.
He will start you at the beginning and cover prerequisites; setting up your development environment first. Afterward, you will use npm to install react-native-cli. The CLI is our go to tool. We use it to create and deploy our app.
Next, you will explore the code. React Native will look familiar to all React developers since it is React. The main difference between React on the browser and a mobile device is the lack of a DOM. We take a look a many of the different UI components that are available.
With React Native you have access to all of the devices hardware features like cameras, GPS, fingerprint reader and more. So we'll show some JavaScript code samples demonstrating it. We will wrap up the evening by deploying our app to both iOS and Android devices and with tips on getting ready for both devices stores.
Алексей Ященко и Ярослав Волощук "False simplicity of front-end applications"Fwdays
It’s easy to underestimate a front-end project's complexity, which leads to shallow and thus incorrect implementation. Attempts to fix this problem result in uncontrolled complexity growth and undefined behavior in corner cases.
We'll discuss ways of revealing the inherent complexity of a problem and dealing with it both on theoretical and practical levels.
Goal setting is important for organisation to realise their mission. Setting an inspirational goal is transforming a whole organisation into sets of focused people to achieve something great, something they can proud of and something everyone really wanted to do.
Northstar metrics is one metrics that matter, it capture the core value that product delivers to customer.
OKR is a framework that encourage a BHAG (Big hairy audacious goal) and select a single Northstart metric to guide organisation achieve great things.
Presentation about my talk in 2nd Product School Jakarta monthly meet up.
I tell a story about the beginning of scientific method used in management and end it with the latest trend of how to use metric to achieve goal.
This is very broad topic, but worth to explore the origin of metrics and how it evolve overtime. Broader discussion would be in Organisational Design of achieving goals.
Presentation at Tokopedia's event Behind Great Product : Build Your Code For the Future. Frandy and Herwidodo was presenting it. It was great experience both of them and they nail it.
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
2. Who am I?
• Ifnu Bima
• Ilmu Komputer IPB, 38
• Join blibli in 2012
• Was working for Deustche Bank Singapore
• Employee no 69
• Engineers no ~13
• Development Manager
– blibli.com Web UI
– Mobile Apps : Android, iOS, Windows Phone
– Content Management System
– Search
– Product Discovery : Wishlist, Product Review
13. What Prevents Clean Code?
Number one reason:
“I’ll clean it up later.”
“Ahh, gampang, ntar
aja, yang penting
beres dulu”
14. The Truth about Clean Code
• Clean Code saves time.
• We can’t take a short-term view of software.
• We need to look at the lifespan of the
application.
15. How Do You Write Clean Code?
Rule of Thumb:
Imagine that the developer who
comes after you is a homicidal
maniac who knows where you
live.
-Unknown
19. Clean Code : Meaningful Names
• Intention-Revealing Names
• Self Explained Names
• theList, x1, y1, i, j, k, index
– Not very good
• productList, indexOfProductList
– A bit better
20. Intention-Revealing Names : Bad
List<int[]> getThem() {
List<int[]> list1 = new ArrayList<int[]>();
for (int[] x : theList) {
if (x[0] == 4) {
list1.add(x);
}
}
return list1;
}
21. Intention-Revealing Names : Good
List<Cell> getFlaggedCells() {
List<Cell> flaggedCells = new ArrayList<Cell>();
for (Cell cell : gameBoard) {
if (cell.isFlagged()) {
flaggedCells.add(cell);
}
}
return flaggedCells;
}
22. Clean Code : Meaningful Names
• Avoid Disinformation
int a = l;
if (O == l) a = O1;
else l = 01;
• Make Meaningful Distinctions
public static void copyChars(char a1[], char a2[]) {
for (int i = 0; i < a1.length; i++) {
a2[i] = a1[i];
}
}
23. Meaningful Names
• Use Pronounceable Names : Bad
class DtaRcrd102 {
private Date genymdhms;
private Date modymdhms;
private final String pszqint = "102";
/* ... */
}
• Use Pronounceable Names : Good
class Customer {
private Date generationTimestamp;
private Date modificationTimestamp;
private final String recordId = "102";
/* ... */ };
}
24. Meaningful Names
• Use Searchable Names : Bad
for (int j = 0; j < 34; j++) {
s += (t[j] * 4) / 5;
}
• Use Searchable Names : Good
int realDaysPerIdealDay = 4;const
int WORK_DAYS_PER_WEEK = 5;
int sum = 0;
for (int j = 0; j < NUMBER_OF_TASKS; j++) {
int realTaskDays = taskEstimate[j] * realDaysPerIdealDay;
int realTaskWeeks = (realdays / WORK_DAYS_PER_WEEK);
sum += realTaskWeeks;
}
25. Meaningful Names
• Avoid mental mapping : Bad
for (i = 0; i < arr.length; i++) {
for (j = i; j < arr.length; j++) {
//bubble sort
}
}
• Dont try to be funny : Bad
public void canggih() {
//TODO
}
27. High Quality Function
• Small!
• rules of functions:
1. should be small
2. should be smaller than that
• < 150 characters per line
• < 20 lines
• Do One Thing
1. FUNCTIONS SHOULD DO ONE THING. THEY
SHOULD DO IT WELL.
2. THEY SHOULD DO IT ONLY.
28. High Quality Function
• DRY : Dont repeat yourself
– Copy paste code everywhere is root of all evil in
software
29. Comments
• Do Not Make Up for Bad Code
– don’t comment bad code, rewrite it!
//edan ini kode siapa yang bikin!!
for (int j = 0; j < 34; j++) {
s += (t[j] * 4) / 5;
}
• Explain yourself in code
// Check to see if the employee is eligible for full
// benefits
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))
{
if (employee.isEligibleForFullBenefits()) {
}
}
30. Comments (good)
• Legal Comments
// Copyright (C) 2017 by blibli.com. All rights reserved.
// Released under the terms of the GNU General Public License
// version 2 or later
• Informative Comments
// Returns an instance of the Responder being tested.
protected abstract Responder responderInstance();
// format matched kk:mm:ss EEE, MMM dd, yyyy
Pattern timeMatcher = Pattern.compile(
"d*:d*:d* w*, w* d*, d*");
31. Comments (good)
• Explanation of Intent
//This is our best attempt to get a race condition
//by creating large number of threads.
for (int i = 0; i < 25000; i++) {
WidgetBuilderThread widgetBuilderThread =
new WidgetBuilderThread(
widgetBuilder, text, failFlag);
Thread thread =
new Thread(widgetBuilderThread);
thread.start();
}
32. Comments (good)
• Clarification
assertTrue(a.compareTo(b) == -1); // a < b
assertTrue(b.compareTo(a) == 1); // b > a
• Warning of Consequences
public static SimpleDateFormat
makeStandardHttpDateFormat() {
//SimpleDateFormat is not thread safe,
//so we need to create each instance independently.
SimpleDateFormat df =
new SimpleDateFormat("dd MM yyyy");
df.setTimeZone(TimeZone.getTimeZone("GMT"));
return df;
}
33. Comments (good)
• TODO Comments
//TODO - MdM these are not needed
//We expect this to go away when we do the checkout model
• Amplification
String listItemContent = match.group(3).trim();
// the trim is real important. It removes the starting
// spaces that could cause the item to be recognized
// as another list.
new ListItemWidget(this, listItemContent,
this.level + 1);
return buildList(text.substring(match.end()));
34. Comments (bad)
• Mumbling
try {
String propertiesPath = propertiesLocation
+ "/" + PROPERTIES_FILE;
FileInputStream propertiesStream =
new FileInputStream(propertiesPath);
loadedProperties.load(propertiesStream);
} catch (IOException e) {
// No properties files means all defaults are loaded
}
35. Comments (bad)
• Redundant Comments
/** * The processor delay for this component. */
protected int backgroundProcessorDelay = -1;
/** * The lifecycle event support for this component. */
protected LifecycleSupport lifecycle =
new LifecycleSupport(this);
/** * The container event listeners for this Container. */
protected ArrayList listeners = new ArrayList();
36. Comments (bad)
• Mandated Comments
/**
* @param title The title of the CD
* @param author The author of the CD
* @param tracks The number of tracks on the CD
* @param durationInMinutes The duration of the CD in minutes
*/
public void addCD(String title, String author,
int tracks, int durationInMinutes) {
CD cd = new CD();
cd.title = title;
cd.author = author;
cd.tracks = tracks;
cd.duration = durationInMinutes;
}
37. Comments (bad)
• Journal Comments
/** Changes (from 11-Oct-2001)
* --------------------------
* 11-Oct-2001 : Re-organised the class and moved it to new
* package com.jrefinery.date (DG);
* 05-Nov-2001 : Added a getDescription() method, and
* eliminated NotableDate class (DG);
* 12-Nov-2001 : IBD requires setDescription() method, now
* that NotableDate class is gone (DG); Changed
* getPreviousDayOfWeek(),
* getFollowingDayOfWeek() and
* getNearestDayOfWeek() to correct bugs (DG);
* 05-Dec-2001 : Fixed bug in SpreadsheetDate class (DG);
* 29-May-2002 : Moved the month constants into a separate
* interface (MonthConstants) (DG);
*/
38. Comments (bad)
• Noise Comments
/**
* Default constructor.
*/
protected AnnualDateRule() {
}
/**
* The day of the month.
*/
private int dayOfMonth;
/**
* Returns the day of the month.
* @return the day of the month.
*/
public int getDayOfMonth() {
return dayOfMonth;
}
39. Comments (bad)
• Scary Noise
/**
* The name.
*/
private String name;
/**
* The version.
*/
private String version;
/**
* The licenceName.
*/
private String licenceName;
/**
* The version.
*/
private String info;
40. Comments (bad)
• Position Markers
// Actions //////////////////////////////////
//End of Actions ///////////////////////////
41. Comments (bad)
• All sort of funny comments and stupid code
// For the sins I am about to commit, may James Gosling forgive me
// If this code works, it was written by Ifnu.
// If not, I don’t know who wrote it
Exception up = new Exception(“Something is really wrong.”);
throw up; //ha ha
//When I wrote this, only God and I understood what I was doing
//Now, God only knows
// I dedicate all this code, all my work, to my wife, Dian, who will
// have to support me and our two children and the cupang once it gets
// released into the public.
42. • All sort of funny comment and stupid code
//Dear future me. Please forgive me.
//I can’t even begin to express how sorry I am.
// Magic. Do not touch.
return 1; # returns 1
/////////////////////////////////////// this is a well
commented line
// I am not sure if we need this, but too scared to
delete.
// I am not responsible of this code.
// They made me write it, against my will.
// If I from the future read this I’ll back in time and
kill myself.
43. Unit Test
• Mengetes logic aplikasi secara otomatis dan
berulang-ulang
• Menghindarkan developer mengetes dengan
manual menggunkan mata
• Menghindari “regression bug”: mengubah
satu kode membuat kode lain jadi error
44. Unit Test
• Membuat developer percaya diri untuk
melakukan refactoring karena ada Unit Testing
• Digunakan secara luas sebagai ukuran internal
code quality
• JUnit secara de facto diterima sebagai tools
untuk Unit Testing di Java