Code Complete: A Practical Handbook of Software Construction, Second Edition

Author: Steve McConnell
All Stack Overflow 109
This Year Hacker News 3
This Month Hacker News 1


by anonymous   2018-01-01

You don't need var before variables here

function doGetWord(){
            var word = F.gword.value;
            var wLength = word.length;

As the idea is to save this values in scope of parent function. And you might replace the letters like this

const letters = document.getElementById("dword").textContent.split('');
letters[i] = dummy;
document.getElementById("dword").textContent = letters.join('');

You are using bad variable names and a lot of global variables, it might be a good practice to work of this. I recommend reading a book on general programming, something like and something more specific to javascript (to get the concept of scopes)

    <!DOCTYPE html>

        <script data-require="jquery@*" data-semver="3.1.1" src=""></script>
            /*body {
                font-family: Calibri;
                font-size: 13.5pt;
                margin-left: 5px;
                color: black;

                border: 1px solid black;

                width: 300px;
                height: 630px;
                border: 0px solid white;
                background-color: white;
                color: white;
                font-family: Arial;
                font-size: 25pt;
        <script src="jquery-3.2.1.js"></script>
        <script type="text/javascript">
            var word = "" //word variable
            var wLength = 0 //word length variable
            var dummy = "" //letter guessed
            var dm = new Array(26)



            function doGetWord(){
                word = F.gword.value;
                wLength = word.length;
                for(var i = 0; i < wLength; i++){
                    document.getElementById("dword").innerHTML += "_ "

            function doGuess(){
                dummy = F.t.value
                if(dummy.length > 1){
                    dummy = ""
                    F.t.value = ""
                    F.t.value = ""
                    alp = ["a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z"];
                    dd = dummy.toString()
                    window["cl" + dd]
                    if(window["cl" + dd] == false){
                        alert("Letter already used, please try again with another letter")
                        dummy = ""
                        F.t.value = ""
                        window["cl" + dd] = false
                        F.t.value = ""

            function doGuessWord(){
                const letters = document.getElementById("dword").textContent.split(' ');
                for(i = 0; i < wLength; i++){
                    if(dummy === word.charAt(i)) {
                        letters[i] = dummy;
                document.getElementById("dword").textContent = letters.join(' ');

        <form name="F">
          <input type="text" name="gword" class="wordi" />
          <input type="text" name="t" class="in2" />
          <input type="button" name="b" value="do" onclick="doGetWord()" class="bi" />
          <input type="button" name="b2" value="do" onclick="doGuess()" class="bi2" />
          <div id="dword"></div>


by anonymous   2017-08-20

For decades programmers have often spent time making software worse by applying practices they don't understand, rather than learning why that practice is good. The use of certain tools/keywords/frameworkes can make a programmer feel sophisticated, when they're just screwing things up. Some common examples:

  • Throwing in lots of try/catch/finally blocks can make a programmer feel like they have an error handling scheme, when in fact they don't.
  • Replacing sql with stored procedures can make programmers feel like they have a data access layer that magically gives them efficiency, reuseability, encapsulation, when in fact they don't.
  • Using classes makes many programmers believe they're engaging in object oriented programming, when in fact they aren't (or are only scratching the surface of OO).

This list could go on forever. This tendency has always been around and always will be, because we humans always look for shortcuts. We see this a lot with patterns now because patterns are currently popular. The root problem is the same: developers not having a respect for how complicated software development is, and thinking a blindly implemented pattern or practice is a substitute for learning and humility.

The solution? Difficult to say. You can't go to wrong though handing a junior developer Code Complete or some such, to help them understand this is all about applying principles to particular situations, and that great developers keep it simple.

by Yuval F   2017-08-20

For decision tables, please see my answer to this question, or better still read chapter 18 in Code Complete 2.

by anonymous   2017-08-20

You might wnat to check out The Definitive C++ Book Guide and List

For your purposes I would especially recommend:

They are not in particular order, also you might want to read and code something in between them.

(Note: As noted by @John Dibling the Boost book might be a bit out of date, I do not have experience with that one myself)

by anonymous   2017-08-20

I'm going to go out on a limb here and suggest that you write some code.

Read Code Complete. Look at other questions about this topic here at StackOverflow. Find an open source project and contribute to it. Start your own pet project that focuses on the skills you're interested in.

When to use Design patterns
How to get into C# Open Source projects

by anonymous   2017-08-20

Should I using other patterns?

No, you should not insist on a single pattern.

No design pattern books will ever advise you to use a single pattern. Just like you cannot chop all ingredients in one single way (are you going to dice the spaghetti?), you cannot organise all logic in one single pattern.

Sure, you can make all your Objects use the initialiser pattern, and don't use constructors at all. This is ok. Been there, done that. I like it.

But these objects can be used with Builder or Abstract Factory (if it make things simpler). As long as the builders/factories themselves have initialiser, and that they properly initialise the created objects, then your use of the initialiser pattern will be consistent. Outside of creational patterns, it is usually good to organise objects with structural and behavioural patterns. They do not conflict with initialiser at all.

For example, look at DOM. All nodes are created by the Document object - elements, text nodes, comments, even events. This is the Factory pattern.

Yet the Document object is also a Facade! From it you access the whole system's status, objects, data, you can even write to it! Every DOM operation starts from the Document, it is the Facade of the DOM system.

DOM nodes also implements multiple patterns. They are organised in Composite, let you listen to events with Observer and Command, and handle events in a Chain of Responsibility. They are certainly parsed by an Interpreter, DocumentFragment is a Proxy, svg elements are implemented as Decorators, and createNodeIterator obviously gives you an Iterator.

The point is, good object-oriented design will yield multiple design patterns as a result, intentional or not.

What are the secrets for good code appearance

I think the best looking code is the one that is easiest to understand to you, and the way you read code changes as you gain more experience.

For example my style is too condensed for most programmers, but to me it strikes a good balance. So do develop your own style - you are not me, and you are not yesterday's you either.

Remember this as we go through the styles.

At the lowest level we have coding style - most importantly indent and bracket.

This one is simple, pick the one you like and stick with it. There are language specific styles, and they are often good starting points. Configure your IDE's formatter so that you can format all your code with hotkey.

Above the code syntax we have comment style and naming convention.

Setting rules on comment is fine, sometimes it is necessary for documenting tools. Avoid too much comment in practice. You may also want to decide your namespace and your stand on naming function expressions.

Above these structures, we have logic conventions.

The same code logic can often be done in many ways, some more 'beautiful' than the others in your eyes. Look at this example.

I picked the second style on first sight: no duplicate, logic is sectioned cleanly, format is not my style but reasonable. But many programmers would prefer the first style: logic is plain as day, a few duplications is worth it. While abstract, this level is quite deep - present your logic the wrong way actually increase the chance an experienced programmer read it wrong.

Finally, we arrives at the level of design pattern, about as far as code beauty goes.

The key to keep your code structure beautiful, is using the right patterns at right level to consistently accomplish loose coupling and code reuse, while avoiding pitfalls and over-design.

There are quite some books about beautiful code, and then there are even more books about designing and implementing beautiful software. (Decide for yourself which are beyond your level.) Knowledge is as important as experience, and you can gain them only by spending your time to study, to write, and to revise/refactor your apps.

Feel free to change your mind as you explore and experiment with your code. Changing your mind is a good sign of learning.

But first, familiarise yourself with design patterns. Just don't forget, they are the generic result of applying object-oriented principals to common tasks. It is still up to you to do the design.

Design Patterns Are Not Silver Bullets.

by anonymous   2017-08-20

Some of policies depend of your programming languages, but :

  1. Write naming rules to uniforme the code of your team
  2. Write general coding rules like KISS principle
  3. For customers and bugs management, take a look at ITIL
  4. For delay and tasks management, I recommand Scrum method
  5. Write a chapter about design patterns (design pattern head first)
  6. If you want more formal procedures, have a look at ISO 90003

Some other books can help you like Code complete

by Bill   2017-08-20

I found that all I need for daily bliss from the CS theoretical world is the utterance of the mantra "Low coupling and High Cohesion". Roger S. Pressman made it scholarly before Steve McConnell made it fashionable.

by anonymous   2017-08-20

You may want to look at books such as Code Complete and Pragmatic Programmer as they also talk about some excellent development principles.