Pants on Fire: 9 Lies That Programmers Tell Themselves

Pants on Fire: 9 Lies That Programmers Tell Themselves

Software developers, like everybody else, aren't always honest with themselves. Here are some common untruths that they can come to believe are true.

Reprint: Pants-on-Fire--9-Lies-That-Programmers-Tell-Themselves

Everybody lies to themselves now and again (“I can’t weigh that much; my scale must be off”) in both their personal and professional lives. Some professions, however, may be more prone to it than others. Software developers, who often work - alone - for long hours under tight deadlines seem to be particularly susceptible to a little self-delusion. By reaching out to developers on social media and reviewing developer comments in discussion forums and elsewhere online, ITworld has compiled 9 of the most common white lies that programmers will tell themselves. How little these white lies are is left up to the reader.

This code doesn’t need commenting

Commenting code is, let's face it, kind of drag, so developers will often find reasons to not do it, or, at least, put it off until later. Sometimes the reasons may be valid but other times, not so much.

"I don't need to comment this, I'll know what's going on. I wrote it for god's sake." Alek

"No one could possibly fail to understand my simple user interface" John Morrow

"I'll remember what I did here without adding a comment to explain it." Avenger

"Code is self documenting." Toby Thain

"I don't need comments because I know what the commands do" Shaun Bebbington

This code doesn’t need commenting

Commenting code is, let's face it, kind of drag, so developers will often find reasons to not do it, or, at least, put it off until later. Sometimes the reasons may be valid but other times, not so much.

"I don't need to comment this, I'll know what's going on. I wrote it for god's sake." Alek

"No one could possibly fail to understand my simple user interface" John Morrow

"I'll remember what I did here without adding a comment to explain it." Avenger

"Code is self documenting." Toby Thain

"I don't need comments because I know what the commands do" Shaun Bebbington

I can do it better myself

The growth of open source has made all sorts of code, tools and applications available to developers for free, but that hasn’t stopped them from often preferring to "role their own." Software engineers are nothing if not a confident in their own abilities.

"My homebrew framework will be nimble, lightweight, debugged, and easy to use." Toby Thain

"I don't need to following the interface norms of X because my way of doing things is better…" Mark Harrison

"I can write assembly that outperforms gcc -O3" Alex Feinberg

"My own parser will do fine." Toby Thain

"My code is better than your code." William Emmanuel Yu

I’ll fix this later

Programmers are often faced with the tradeoff of doing something fast or doing it "right," whether it's to fix a critical bug or meet a deadline. Coding compromises are often made in the name of saving time with the intention to fix or clean up the not-quite-perfect code later - often with the knowledge that later will never come.

"I know this is dirty code, I will rewrite it later." GerardYin

"We'll fix this in a later release." notgeorgelucas

"I'll come back and comment this later" schrodingerspanda

"This bug can be ignored for now" makemehumanagain

"I'll refactor this before I release it." Dave Cole

It’s only a small change

When making a change to code, either to fix a bug or add some functionality, even the smallest tweak can often turn into a bigger task than expected due to unexpected dependencies. No matter how many time they've experienced this, though, coders can still forget that there are rarely truly minor code changes.

"That is going to be a simple minor change." Hummigbird1

"It's just one line... it won't break anything" bleepster

"it will not affect the rest of the program code!" just cool stuff

"No need for database transactions, nothing can possibly fail here!" Ahmet Alp Balkan

"This minor unrelated change in the code could not possibly be the cause for the unit tests failing." Hummigbird1

It’s not a bug

Sometimes developers don't like to admit that their code is doing something wrong or has a bug. After all, they wrote it, they tested it (hopefully) and it works fine for them. Either the users are doing something wrong or they just misunderstand how the tool or application is supposed to work. At least that's what a developer may think.

"It works on my machine" Madsdad

"It's not a bug, it's a feature!" Ron007

"if it compiles, it must be correct!" Philip Guo

"If it passes tests, it must be correct." Michal Pise

"It works" Alec Heller

I know what I’m doing

Programmers' overconfidence can sometimes, wrongly, convince them they know what they're doing which, believe it or not, isn't always the case. It can lead them to cut corners, charge blindly into the fray or generally not be careful, all of which can lead to trouble.

"I can skip design and architecture and leap right into coding." Toby Thain

"I totally understand that legacy code!" Hummigbird1

"I know what the client wants." DutchS

"I don't need version control." Toby Thain

"I know what I'm doing." Kyle

I can safely skip that test

Testing is a necessary part of creating software and not always so much fun. Much like writing comments, programmers can sometimes find an excuse for not writing or performing tests or otherwise properly putting their code through it’s paces.

"Tests are usually redundant, it is working now with this input and it proves that." Ahmet Alp Balkan

"If I write some unit tests, I don't need type checking." Toby Thain

"It's a simple one-line change, we don't need to test it." Sami Kukkonen

I’m using <NAME OF FAVORITE PROGRAMMING LANGUAGE HERE> so we’re good

Software developers have their favorite programming languages, ones that they come to know well, trust and depend on. Their love of and loyalty to their favorite language, however, can sometimes make them less than honest with themselves about that language’s possible faults, drawbacks or limitations.

"If it's written in C, it will be fast." Toby Thain

"It's written in Python, so it's easy to extend." Alec Heller

"Java runs everywhere." Ahmet Alp Balkan

Sonar - Teamforge integration plugin

Just created my first sonar plugin. It's about integration between Sonar and TeamForge.
By default you can get only Sonar+JIRA.

Few screenshots to show you what is all about:

1) When your Sonar find issues you'll have new action: Link to TeamForge

On click - new artifact (Task/Defect - configurable by admin) will be created in TeamForge.

2) In TeamForge you can see new artifact created:

3) There is also back connection (link) in Sonar:

You can download it from: sourceforge.net

Source code is here: code.google

SVN hooks to automatically check code with PMD (or checkstyle)

I just finished PoC for creating SVN hook with PMD (easily replaced with PMD or  git instead svn).

Functionality:

Every time developer commit java source code to repository (svn), pre-commit hook will call PMD http://pmd.sourceforge.net/. If there will be violations - error with detailed description will be generated, and developer will be stopped from committing bad code. 

Solution is based on standard svn example for validate-files. I did PoC on windows machine - so I have to spend some additional time to fight with .bat->.py integration, but mac/linux should me much more easier /straight forward solution.
Prerequisites are: svn + java + python + pmd.

Installation steps:
1) Create your SVN repository:

svnadmin create c:\svnrepo

2) Copy into hooks directory: (c:\svnrepo\hooks)
2.a) pre-commit.py

#!/usr/bin/env python 
"""Subversion pre-commit hook script that runs PMD static code analysis.

Functionality:
Runs PMD checks on java source code.
Commit will be rejected if PMD rules are voilated.
If there are more than 40 files committed at once - commit will be rejected.
Don't kill SVN server - commit in smaller chunks. 
To avoid PMD checks - put NOPMD into SVN log.
The script expects a pmd-check.conf file placed in the conf dir under
the repo the commit is for."""
 
import sys
import os
import subprocess
import fnmatch
import tempfile
 
# Deal with the rename of ConfigParser to configparser in Python3
try:
    # Python >= 3.0
    import configparser
except ImportError:
    # Python < 3.0
    import ConfigParser as configparser
 
class Commands:
    """Class to handle logic of running commands"""
    def __init__(self, config):
        self.config = config
 
    def svnlook_changed(self, repo, txn):
        """Provide list of files changed in txn of repo"""
        svnlook = self.config.get('DEFAULT', 'svnlook')
        cmd = "%s changed -t %s %s" % (svnlook, txn, repo)
        # sys.stderr.write("Command:: %s\n" % cmd)
        p = subprocess.Popen(cmd, shell=True,
                             stdout=subprocess.PIPE, stderr=subprocess.PIPE)
 
        lines = (line.strip() for line in p.stdout)
        # Only if the contents of the file changed (by addition or update)
        # directories always end in / in the svnlook changed output
        changed = [line[4:] for line in lines if line[-1] != "/"
            and line[0] in ("A","U") ]

        # wait on the command to finish so we can get the
        # returncode/stderr output
        data = p.communicate()
        if p.returncode != 0:
            sys.stderr.write(data[1].decode())
            sys.exit(2)
 
        return changed
 
    def svnlook_getlog(self, repo, txn):
        """ Gets content of svn log"""
        svnlook = self.config.get('DEFAULT', 'svnlook')
 
        cmd = "%s log -t %s %s" % (svnlook, txn, repo)
 
        p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, 
                             stderr=subprocess.PIPE)
        data = p.communicate()
 
        return (p.returncode, data[0].decode())
 
   
    def svnlook_getfile(self, repo, txn, fn, tmp):
        """ Gets content of svn file"""
        svnlook = self.config.get('DEFAULT', 'svnlook')
 
        cmd = "%s cat -t %s %s %s > %s" % (svnlook, txn, repo, fn, tmp)
 
        p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, 
                             stderr=subprocess.PIPE)
        data = p.communicate()
 
        return (p.returncode, data[1].decode())
 
    def pmd_command(self, repo, txn, fn, tmp):
        """ Run the PMD scan over created temporary java file"""
        pmd = self.config.get('DEFAULT', 'pmd')
        pmd_rules = self.config.get('DEFAULT', 'pmd_rules')
 
        cmd = "%s -f text -R %s -d %s" % (pmd, pmd_rules, tmp)
 
        p = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE, 
                             stderr=subprocess.PIPE)
        data = p.communicate()
 
        # pmd is not working on error codes ..
        return (p.returncode, data[0].decode())
 
 
def main(repo, txn):
    exitcode = 0
    config = configparser.SafeConfigParser()
    config.read(os.path.join(repo, 'conf', 'pmd-check.conf'))
    commands = Commands(config)
 
    # check if someone put magic string to not process code with PMD
    (returncode, log) = commands.svnlook_getlog(repo, txn)
    if returncode != 0:
        sys.stderr.write(
            "\nError retrieving log from svn " \
            "(exit code %d):\n" % (returncode))
        sys.exit(returncode);
       
    if "NOPMD" in log:
        sys.stderr.write("No PMD check - mail should be sent instead.")
        sys.exit(0)
       
    # get list of changed files during this commit
    changed = commands.svnlook_changed(repo, txn)
 
    # this happens when you adding new project to repo
    if len(changed) == 0:
        sys.stderr.write("No files changed in SVN!!!\n")
        sys.exit(0)
 
    # we don't want to kill svn server or wait hours for commit
    if len(fnmatch.filter(changed, "*.java")) >= 40:
                sys.stderr.write(
            "Too many files to process, try commiting " \
            " less than 40 java files per session \n" \
            " Or put 'NOPMD' in comment, if you need " \
            " to work with bigger chunks!\n")
        sys.exit(1)
 
    # create temporary file
    f = tempfile.NamedTemporaryFile(suffix='.java',prefix='x',delete=False)
    f.close()
 
    # only java files
    for fn in fnmatch.filter(changed, "*.java"):
        (returncode, err_mesg) = commands.svnlook_getfile(
            repo, txn, fn, f.name)
        if returncode != 0:
            sys.stderr.write(
                "\nError retrieving file '%s' from svn " \
                "(exit code %d):\n" % (fn, returncode))
            sys.stderr.write(err_mesg)
           
        (returncode, err_mesg) = commands.pmd_command(
            repo, txn, fn, f.name)
        if returncode != 0:
            sys.stderr.write(
                "\nError validating file '%s'" \
                "(exit code %d):\n" % (fn, returncode))
            sys.stderr.write(err_mesg)
            exitcode = 1
        if len(err_mesg) != 0:
            sys.stderr.write(
                "\nPMD violations in file '%s' \n" % fn)
            sys.stderr.write(err_mesg)
            exitcode = 1
           
    os.remove(f.name)
    return exitcode
 
if __name__ == "__main__":
    if len(sys.argv) != 3:
        sys.stderr.write("invalid args\n")
        sys.exit(1)
 
    try:
        sys.exit(main(sys.argv[1], sys.argv[2]))
    except configparser.Error as e:
       sys.stderr.write("Error with the pmd-check.conf: %s\n" % e)
        sys.exit(1)

2.b) pre-commit.bat [ if this is windows ]

c:/python27/python pre_commit.py %1 %2
exit %ERRORLEVEL%;

you can change paths to python/repository


3) Copy pmd-check.conf into conf directory (c:\svnrepo\conf)

[DEFAULT]
svnlook = c:\\opt\\svn\\svnlook.exe
pmd = c:\\opt\\pmd\\bin\\pmd.bat
pmd_rules = java-basic,java-braces,java-clone,java-codesize,java-comments,java-design,java-empty,java-finalizers,java-imports,java-j2ee,java-javabeans,java-junit,java-logging-java,java-naming,java-optimizations,java-strictexception,java-strings,java-typeresolution,java-unnecessary,java-unusedcode
 
#not in scope
#java-controversial, java-coupling, java-android, java-javabeans, java-logging-jakarta-commons, java-sunsecure
#java-migrating, java-migrating_to_13, java-migrating_to_14, java-migrating_to_15, java-migrating_to_junit14

And this is file that you should change depending on your svn/pmd installation paths and what PMD rules you want to check.


Final tip: To avoid PMD check on top of standard PMD suppressers - you can just put "NOPMD" into comment.

Have fun!
/Jaro

automatic jUnit test generators - review

This could be scary one. 

When I heard term “automatic jUnit test generator” I was thinking: “no one should go that path”, ”units test should be written by the developers”, “do you want to replace devs?”, “test should be written before code!”.

But I gave it closer look, and actually “closer think” – did I really expect that there is some AI module which will go through code and automatically write tests – if so why there is no AI which automatically write code in first place … [maybe soon ;-)]

Before you send thousands of hate comments, let’s give it quick look what is definition and what should you expect by automatic jUnit test generator:

• it's everywhere - right click on class in eclipse or intelliJ and you’ll have it - that's point first and should be breakthrough in your thinking about generators ;-)
• if you want to write jUnit for class A that is dependent on: log, dbDao, jmsHelper, etc... - there are few different schools, but for simplicity let’s say that you'll write mocks for each of them
• then if you'll have:
• class B,C dependent on jmsHelper and log
• class D,E dependent on dbDao and log
• etc ...
• and there is team of people working on same code

Result => we will see developer per class / copy-paste pattern.

What if instead standard eclipse jUnit plugin you’ll use tool that where you'll create "mappers/patterns" for each class that will produce that mocks automatically?

Then you'll run "generator" and it will create same structure as eclipse/intelliJ "right click", but with all mocks already copied - no need to create boilerplate code by each developer separately?

And … there will be no real test code there - plain output jUnit just like in "right click".

If I calculate it properly, I spend like 50% of testing time - writing boilerplate code [setting up all mocks, adding standard "patterns", etc...].

To speed up it I usually finish with copy-paste pattern which from other hand I'm extreme oppositionist.

Using generators I'll not to do it again - yes, of course I need to do it once at beginning, maybe some maintenance, but then it will be reused, and whole solution will be consistent.

So, now we should be on same page.

At first I was skeptic if something like that could exist, but ..

Generators:

I've take 4 generators for review:

• AgitarOne
• JTest - Parasoft
• Randoop
• CodePro AnalytiX - google

there are probably more - but to speed up process of speeding up process I  also have some time constrains  ;-)

Test scenario:

1.     Choose few most “typical” classes for that project – together easy and more complicated.

2.     Using different tools generate test cases.

3.     Compare generated jUnits from usability perspective (what was generated, how many methods, what amount of code was there,..)  also from percentage of code covered.

Output:

• AgitarOne - quite nice, but is not generating plain jUnits, there is strong dependency on Agitar version of jUnits and if you don’t have license it will not work - so I’ll not take it into consideration [commercial]
• Randoop - created random "stress" test cases, quite different from others - delivers almost full tests, finds typical corner case scenarios (NPE, OutOfIndex, ..) [opensource]
• jTest Parasoft - created boilerplate test code using plain jUnit (which is significant plus compared to Agitar) - it works just like standard jUnit eclipse/intelliJ plugin which means one test for one method, no code analysis[commercial] 
• CodePro AnalytiX - created boilerplate test code using plain jUnit and EasyMock, with static code analysis - created number of test per method depends on "if-cases" which was quite good especially in the case when we go through existing stuff - definitely that will speed up writing, there are other cool tools in the pack, supporting: code coverage, dependency analysis, metrics computation, audit, etc... which also is pretty cool as developer don't need to wait till Sonar give you stats after commits - you can have it on-demand [freeware]

Recommendation / Winner:

CodePro AnalytiX

Discussion:

CodePro is good call - is generating lots of boilerplate code for a developer and save lots of time. Still complex code cannot be completely automated, and developer need to fill gaps - but it is showing you that gaps, suggesting what should be tested.

In different scenario (and I'm thinking also about code reviews) I will give a try to randoop - as is generating whole test, developer  don't need to touch the code (almost ;-) ), and is testing specific corner cases - which you can miss otherwise.

Note:

Of course there are some promises that "generators will exercise" code, which at end will look like (i.e.: method that is adding two ints):

public void testAdd_1() throws Exception

{

     int x=1;

     int y=2;

     int result = Tested.add(x, y);

    // add test code here

}

Still developer need to go there and:

- add asserts,

- change name of the method to something meaningful,

- add comments,

- [change whatever is specific to your team process/code quality]

I my opinion CodePro is really good replacement for standard eclipse jUnit generator - in worst case (day first) you'll have exactly same output, in best case - you'll need to add only asserts!

14 funny dev jargon found on code horror

1. Jenga Code

It's when the whole thing collapses after you alter a block of code!

2. Megamoth

It stands for MEGA MOnolithic meTHod, often contained inside a God Object, the Megamoth usually stretches over two screens in height.

Megamoths as large as 2k LOC have been sighted!

3. Reality 101 Failure

This program does exactly what is told, although when it's deployed it turns out that the problem was misunderstood. So basically, it is useless! 

4. Bicrement

Adding 2 to a variable.

5. Banana Banana Banana 

Placeholder text indicating that documentation is in progress or yet to be completed. 

Mostly used since FxCop complains when a public function lacks documentation. 

6. Protoduction

A prototype that eventually ends up in production.

7. Smurf Naming Convention

When almost every class has the same prefix. 

8. Common Law Feature

A bug in the application that has been there so long that it is now part and parcel of the expected functionality, 

User support is required to actually fix it.

9. Hindenbug

A catastrophic data destroying bug. 

Related to Counterbug and Bloombug.

10. Nopping

comes from assembler NOP for no-operation.

When writing something from the POV of an AI, and their internal language has a lot of programming jargon in it. 

11. Doctype Decoration

When web designers add a doctype declaration but don't write a valid markup. 

12. Heisenbug

Bug that disappears or alters its characteristics when an attempt is made to study it.

13. Stringly Typed

A riff on strongly typed. 

Used to describe an implementation that needlessly relies on strings when programmer & refactor friendly options are available. 

14. Smug Report

A bug submitted by a user who thinks he knows a lot more about the system's design than he really does. 

Filled with irrelevant suggestions that are always wrong about what he thinks is causing the problem and how we should fix it. 

Source: Coding Horror

Common basic style errors.

Nothing new - just to remember (found in some old txt file)

• classes too long
• methods too long
• little or no javadoc
• no convention for distinguishing between local variable, arguments and fields
• many empty catch books that suppress exception
• inappropriate use of multiple return statements
• using exception to define regular program flow
• excessive use of the instance of operator
• using floating point data to represent money
• preferring arrays over collections
• not ordering class members by scope

3 easy step to test your website with Selenium from Java.

In this post I want to cover how quickly test website with Selenium.

In my scenario I had issue on some prod server where after some time we get OOM (OutOfMemory), server is .net IIS, after few quick manual test we was not able to reproduce issue on any our test env. So then Selenium comes to play.

Step one: download.

Selenium IDE is written on top of Firefox - it is Firefox plugin. Download it from:

http://docs.seleniumhq.org/download/ 

You need 2 pieces to play: IDE and server. When you install IDE, you'll be ask to restart browser, then you'd see in the tools menu "Selenium IDE".

Step two: record & replay.

You're ready to play - just create your test case, click on "Record" and open the page that you want to play with.

Finish of that is script containing steps that you was doing on page. Replay them to make sure that everything is working. If you'll have error that server is not ready: go to command line and start selenium server: java -jar selenium-server-standalone-{version}.jar 

My advice is to do this step couple of time to get familiar how Selenium is working / how is recording steps-clicks, and how actually replay is going through your website - also it looks cool ;-).
When you finish - save it. You also can export it - in my case I export it to jUnit4 format.

Step three: jUnit.

Run from your development IDE (eclipse/netbeans/intelliJ/..).

Create new project in eclipse, then copy body of generated jUnit from previous step. To run test in eclipse you need libraries, you can download them from same page:  http://docs.seleniumhq.org/download/. Just add them to your project dependency... and you ready to rock.

You can also use this example maven project:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

  <modelVersion>4.0.0</modelVersion>

  <groupId>com.yarenty.uitest</groupId>

  <artifactId>selenium</artifactId>

  <version>0.0.1-SNAPSHOT</version>

  <dependencies>

   <dependency>

        <groupId>org.seleniumhq.selenium</groupId>

        <artifactId>selenium-firefox-driver</artifactId>

        <version>2.38.0</version>

    </dependency>

  </dependencies>

</project>

How to make concurrent calls? use Executors from my post: http://yarenty.blogspot.com/2012/01/template-multithreading-solution-using.html

       public void start(){

                ExecutorService executor = Executors.newFixedThreadPool(CONCURRENT_USERS);

                  List<Future<Long>> list = new ArrayList<Future<Long>>();

                  for (int i = 0; i < NUMBER_OF_USER_SESSIONS*CONCURRENT_USERS; i++) {

                    Callable<Long> worker = new FirefoxWorker(i);

                    Future<Long> submit = executor.submit(worker);

                    list.add(submit);

                  }

                  // now retrieve the result

                  for (Future<Long> future : list) {

                    try {

                      future.get();

                    } catch (InterruptedException e) {

                      e.printStackTrace();

                    } catch (ExecutionException e) {

                      e.printStackTrace();

                    }

                  }

                  executor.shutdown();

       }

CONCURRENT_USERS - is what is the number of users accessing webpages at single time.
NUMBER_OF_USER_SESSIONS - is how many interactions do you want to have.
Overall number of "visits" is multiplicity of both above.

In my solution I created user_id adding to standard user "i" - next number of execution. You may think about different solution - Hopefully I can present you how to incorporate Disruptor with defined handlers, ... soon ;-)