Reddit Reddit reviews Clean Code: A Handbook of Agile Software Craftsmanship

We found 426 Reddit comments about Clean Code: A Handbook of Agile Software Craftsmanship. Here are the top ones, ranked by their Reddit score.

Computers & Technology
Computer Programming
Software Design, Testing & Engineering
Software Development
Clean Code: A Handbook of Agile Software Craftsmanship
Prentice Hall
Check price on Amazon

426 Reddit comments about Clean Code: A Handbook of Agile Software Craftsmanship:

u/batmassagetotheface · 383 pointsr/learnprogramming

I always recommend this book called 'Clean Code'
It details a collection of techniques to keep your code readable and maintainable.
In general use good variable and method names and use more, shorter methods where appropriate

u/samort7 · 257 pointsr/learnprogramming

Here's my list of the classics:

General Computing

u/_a9o_ · 188 pointsr/cscareerquestions

Refactoring: Improving the design of existing code

Design Patterns

Working Effectively with legacy code

Clean Code

How to be a programmer

Then there are language specific books which are really good. I think if you read the above, slowly over time, you'll be in a great place. Don't think you need to read them all before you start.

u/_dban_ · 168 pointsr/programming

Isn't this argument kind of a strawman?

Who says that self-documenting code means absolutely no comments? Even the biggest champion of self-documenting code, Uncle Bob, devotes an entire chapter in Clean Code to effective commenting practices.

The idea of "self-documenting code" is that comments are at best a crutch to explain a bad design, and a worst, lies. Especially as the code changes and then you have to update those comments, which becomes extremely tedious if the comments are at too low a level of detail.

Thus, while code should be self-documenting, comments should be sparse and have demonstrable value when present. This is in line with the Agile philosophy that working code is more important than documentation, but that doesn't mean that documentation isn't important. Whatever documents are created should prove themselves necessary instead of busy work that no one will refer to later.

Uncle Bob presents categories of "good comments":

  • Legal Comments: Because you have to
  • Informative Comments, Clarification: Like providing a sample of a regular expression match. These kinds of comments can usually be eliminated through better variable names, class names or functions.
  • Explanation of Intent
  • Warning of Consquences
  • TODO Comments
  • Amplification: Amplify the importance of code that might otherwise seem consequential.
  • Javadocs in Public APIs: Good API documentation is indispensable.

    Some examples of "bad comments":

  • Mumbling
  • Redundant comments that just repeat the code
  • Mandated comments: aka, mandated Javadocs that don't add any value. Like a Javadoc on a self-evident getter method.
  • Journal comments: version control history at the top of the file
  • Noise comments: Pointless commentary
  • Closing brace comments
  • Attributions and bylines
  • Commented out code
u/YuleTideCamel · 162 pointsr/learnprogramming
  • Clean Code is a really good programming book. It's technical in that it gives you best practice, but you don't need a laptop or to code to follow along, you can just absorb the information and follow along with the simple samples (even if it's not your primary coding language).

  • The Clean Coder is a great book about how to build software professionally. It focuses on a lot of the softer skills a programmer needs.

  • Scrum: The Art of doing twice the work in half the time is a great introduction to scrum and why you want to use it. Agile (and scrum in particular) can have a major improvement on the productivity of development teams. I work for a large technology company and we've seen improvements in the range of 300% for some teams after adopting scrum. Now our entire company is scrumming.

  • Getting Things Done has personally helped me work more efficiently by sorting work efficiently. Having a system is key.

  • How to Win Friends and Influence People I often recommend devs on our team read this because it helps with interpersonal communication in the office.

  • Notes to a Software Tech Lead is a great book so you can understand what a good lead is like and hopefully one day move up in your career and become one.

u/TheAmazingSausage · 128 pointsr/androiddev

Android team lead here, I've been working with Android commercially since 2009 (before Android 2.0 was released) and have worked at, or done work for, some big companies (Mozilla, Intel, Google, HTC...). I was in a very similar situation to you in that I was a web development and was bored, I'd been playing with Android in my spare time; I got my first break by volunteering to do an android app at the company I worked for, and went from permanent employee to contractor fairly quickly after that and have been doing it ever since.

First thing to say is that if you can get your currently company to pay you to learn android and stay with them, that's a win win for both parties (you get to learn something new without a drop in salary and don't have to interview and they don't lose a good member of staff).

In terms of moving company, I don't know where you are based, but here in the UK I often see junior Android contract roles coming up for £200-300 a day. Failing that it's just a case of applying for lots of poisitions and really knowing your stuff.

What I would look for in a junior is to have read, understood and put in to practice Clean Code ( and Design Patterns ( I would expect you to have a good understanding of basic Java and OOP; a working understanding of MVP or MVVM (,; understand threading; know about all the major parts of Android (Services, Broadcast receviers, Activities, Fragments etc); know how to write a custom view; be able to efficiently design a layout in XML and correctly apply styles and themes; understand the support libraries - what they contain, why they exist and what they are used for (and also when you don't need them); understand the difference between unit testing and integration testing and know what makes for a good test; the Gradle build system is a really nice way of defining your project build - knowing the fundamentals is essential.

A few of the main libraries I'd expect you to know and have used would be OkHttp (, Retrofit (, Butterknife (, Picasso ( or some other image loading library, GSON ( or Moshi ( or some other json parsing library

If you want to level up then there are loads of advanced topics surrounding Android. Any of these following topics will take a while to learn, but will be worth it and will look good in interviews and on you CV:

u/phpdevster · 87 pointsr/webdev

You need to build up a foundational set of programming skills. Frameworks and libraries are important to know, but not as important as knowing how to program. The difference between a program/website/webapp that works, and a program/website/webapp that works AND has sensible code, is significant to a company. I've seen the simplest of features take weeks to implement in very poorly written code bases. This is valuable and expensive time that could have been spent building other features.

Companies are sensitive to this because very few companies are immune to the effects of poorly written and maintained code bases, so they are going to ask you code design questions and even have you do live programming challenges to see how think about the problem, and whether the design of a solution is important to you, or whether you're content to just shit out any old solution that works and move on.

To start, with, I would familiarize yourself with the basic mechanics of the language by reading the You Don't Know JS series:

Next, I would read Clean Code by Robert Martin. It's based in Java, but the general principles are the same.

Next, I would read Refractoring: Improving the Design of Existing Code (2nd edition - which is JavaScript based). You can read the Java-based 1st edition for free.

Finally, I would read A Mostly Adequate Guide to Functional Programming.

Yes, it's a lot of reading, but these books will help you think about your code design choices, and in combination with practice, will help you write better code. But of course there is no substitute for practice. The more you write code, the better you'll be at it. The resources I linked to are just guides, not magic bullets.

In terms of other things that are necessary to learn, you'll need to learn how to use git (not to be confused with GitHub). Git is basically the industry standard version control system. You don't have to be an expert at it, but you do need to know the basics of it.

You're also going to want to get familiar with the basics of node and npm, because even doing front-end work, you'll be relying on 3rd party packages, and running builds, all of which are managed through node and npm (or yarn).

u/username-proxy · 51 pointsr/learnprogramming
u/Nezteb · 43 pointsr/compsci

Some book recommendations:

u/geek_on_two_wheels · 33 pointsr/csharp
u/LunarKingdom · 31 pointsr/gamedev

If you write your code in a meaningful, clean and understandable way itself, comments are almost useless and, in many cases, a source of misunderstanding and mistakes (especially working with other people). If you add too many comments, you need to update them with every single change you make to the code to keep them useful, which is an extra maintenance cost.


  • Name your variables and methods properly, sometimes people name things with cryptic and short names hard to understand.
  • Use refactoring techniques, design patterns (when appropriate) and SOLID principles to make code clean, familiar, easy to maintain and extend.

    After 10 years of experience as a programmer working on different teams, my opinion is the fewer comments, the better.

    I recommend you this book, a classic:
u/hrastignac · 28 pointsr/learnprogramming

Clean Code is widely considered (at least in my circles) as a "must read" position for a pragmatic coder.

u/Vitate · 26 pointsr/cscareerquestions

Much of this stuff is learnable outside of work, too, at least at a superficially-passable level. Trust me.

Pick up a few seminal books and read them with vigor. That's all you need to do.

Here are some books I can personally recommend from my library:

Software Design

u/feketegy · 25 pointsr/PHP

Every quality software should have tests. So...

Read the unit tests / features tests first. Those will show you how a specific piece of the code works.


  1. Play with composer packages.
  2. Learn about PHP SPL
  3. Learn about design patterns and beyond
  4. Learn TDD, setup PHPUnit, Behat, Mink, PHPSpec
  5. Read PHP The Right Way
  6. Learn about clean code, EBI, DCI and how to put MVC on a shorter leash here: and here and check out the #cleancode IRC channel on freenode
  7. Read a couple of books like: PHP Objects, Patterns and Practice or Code Complete or Clean Code or The Pragmatic Programmer or The Mythical Man-Month
  8. Start an open-source project or contribute to one

    There are a lot to learn and if you really like programming you will never stop learning.

u/MemeSearcher · 24 pointsr/learnprogramming

A good book for you would be clean code. I'm only part way into it, but it's a really good resource for learning better code practices. You won't find much commenting in there, however, as their philosophy is that you shouldn't need comments if you do it right. It might be a good place to start if you're willing to look for good commenting practices elsewhere

u/abstractifier · 22 pointsr/learnprogramming

I'm sort of in the same boat as you, except with an aero and physics background rather than EE. My approach has been pretty similar to yours--I found the textbooks used by my alma mater, compared to texts recommended by MIT OCW and some other universities, looked at a few lists of recommended texts, and looked through similar questions on Reddit. I found most areas have multiple good texts, and also spent some time deciding which ones looked more applicable to me. That said, I'm admittedly someone who rather enjoys and learns well from textbooks compared to lectures, and that's not the case for everyone.

Here's what I gathered. If any more knowledgeable CS guys have suggestions/corrections, please let me know.

u/diablo1128 · 20 pointsr/cscareerquestions

Clean code by Robert Martin AKA Uncle Bob.

He also has a website with videos that go over topics from the book and more:

u/Nugsly · 20 pointsr/csharp

I'm going to start by assuming this may be maintained by another person at some point in the future. First off, naming. Although it is kinda targeted towards Java, the majority is directly applicable to C#. Clean Code. The underscores and you prefixing an abbreviation for the type should be changed. An example would be:


Changes to:


because of the fact that it is a public property, and you've already told us it is an Int when you declared it. Doing this will allow others to maintain your code with less headache. is an MSDN article that goes over some of it.

Next, spaces in the folder names, you should avoid that for the same reason above, use PascalCase, no spaces, no hyphens, no underscores if possible.

You have no guard clauses in there. An example of adding one in would be (Line 31 'DataObjects.cs):

if (string.IsNullOrEmpty(displayLine1)) throw new ArgumentNullException("displayLine1");

Favor guard clauses over exception handling wherever possible. When you need to handle exceptions, handle them specifically. If the code you are calling can throw an InvalidOperationException, favor catching that over just Exception. Exceptions should be exceptional, not a common occurrence in your code, guard clauses help with that. Another example would be (Line 96 'Program.cs'):

if (File.Exists(s_directory + @"\Bricks.xml") { ...the rest of the code that uses that file here }

Use meaningful names. 'displayLine1' as a constructor parameter is ambiguous. Sometimes it makes sense to shorten some of the names as well; 'customerWhoPurchasedId' could just be 'customerId'.

In DataObjects.cs, you are returning '-1' as an error, I would use something more meaningful than a number. If you are going to use a number like that, use an enum so that you can read your code using friendly names, '-1' is ambiguous, but something like BrickSearchResult.Empty is not.

Style out of the way, now let's move on to data. You are a database guy. I would suggest using a database to store the data over an xml file.

Next. You are doing a ton of work in your application's main constructor. Move that code out of there, and let it initialize the app unimpeded. People debugging your code later will thank you. I would suggest using the Form_Loaded or whatever the Forms equivalent for Window_Loaded is.

On a general note, follow the principle of having each small piece of code do one thing, and one thing only. Your main class is also responsible for data access, it should not be. You should have separate classes for that, this is called 'separation of concerns'. Your CRUD operations should all be in the same class. Each class should have its own file whenever possible. So 'DataObjects.cs' would be split into 'Customer.cs' and 'Brick.cs'. Keep in mind that you can use folders in your solution as well to keep things a bit more organized.

You are welcome to PM me if you have other questions.

u/schroet · 20 pointsr/cscareerquestions

This is a good start to get a taste of good code:

Many developers recognize this practices and value them very much.

u/denialerror · 19 pointsr/learnprogramming

Just keep learning for now and focus on building your understanding of programming, rather than syntax or following convention. Despite what a lot of people tend to say, unlearning habits in not hard, especially as a beginner. Focusing too much on best practices early on will be an unnecessary distraction when you already have a lot of new things to try and get your head around.

When you get more proficient and start needing to worry about best practices, read Clean Code.

u/DeliveryNinja · 18 pointsr/learnprogramming

You mention you have a very experienced team around you, this is your best resource. When I started my first coding job, the people around me really helped me become a much better developer. Ask for advice when you are stuck, think about best practices and sit with them and do the code reviews together. If they are writing good code then use their code as a guide for your own. You will soon learn the skills for yourself and realise that it's not as daunting as it seems as long as you can code basic programs. Something you can do to get a better feel for how your basic programs create something larger is to get them to walk you through the architecture.

One thing I did when I started was ask my team leader where I could improve and he recommended me some books. Have a look at head first design patterns, clean coder and growing-object-oriented-software. These are Java based but are applicable to any language.

u/usernamesarethebane · 18 pointsr/java

Go read Clean Code: A Handbook of Agile Software Craftsmanship and write beautiful code yourself.

u/RetroTK2 · 17 pointsr/Unity3D

> I know programming

I have a checklist I usually bring out at this point :) You should know:

  • understanding different basic data types (ints, floats, bool, string) and how to manipulate them (especially strings)
  • understanding the difference between properties and fields.
  • If and switch statements
  • Ternaray Operators
  • Basic Mathematical Operators (*, +, =, etc);
  • understand the difference between = and ==, and not operators (!(true) and !=)
  • Advanced Mathematical Operators (+=, % for modulus , << left bit shift operator)
  • Arrays and Lists
  • Dictionaries and Keypairs
  • Understanding objects, classes and constructors
  • New Keyword
  • Access Modifiers and Static
  • Understanding references and null values
  • Inheritance
  • Indexers
  • Namespaces and using
  • Partial Keyword and why it's a good idea to limit the use of it
  • Abstract classes and interfaces
  • Delegates, Events, Action and Func
  • Understanding generics and using <T>.
  • Casting types with 'as' or direct and understanding the difference
  • Serialization
  • Comments and Regions
  • Threading
  • ref and out keywords and why they can be bad to use
  • IEnumerable and Yield Return
  • Enums and flags
  • Understanding Loops (while, foreach, for and do) and the differences between all of them
  • continue and break keywords and how to use them in loops
  • try,catch and finally
  • Understanding methods: void, return types and parameters
  • overloading methods
  • Knowing what the params keyword is and how to use it in methods
  • what virtual and override are and how they can be used

    If you confident you have all this you'll probably want to start learning about design patterns and decoupling techniques. This free online book is amazing, and I would recommend it to everyone:).

    Other books like Clean Code and The Art of Unit Testing have helped me a lot too.

    With coding, it because more about creating code that is easy to change. I would also recommend using StrangIoc along with MVC to achieve decoupled, clean code:)
u/Cohesionless · 17 pointsr/cscareerquestions

The resource seems very extensive such that it should suffice you plenty to be a good software engineer. I hope you don't get exhausted from it. I understand that some people can "hack" the technical interview process by memorizing a plethora of computer science and software engineering knowledge, but I hope you pay great attention to the important theoretical topics.

If you want a list of books to read over the summer to build a strong computer science and software engineering foundation, then I recommend to read the following:

  • Introduction to Algorithms, 3rd Edition: A lot of people do not like this classic book because it is very theoretical, very mathematical, and very abstract, but I think that is its greatest strength. I find a lot of algorithms books either focus too much about how to implement an algorithm in a certain language or it underplays the theoretical foundation of the algorithm such that their readers can only recite the algorithms to their interviewers. This book forced me to think algorithmically to be able to design my own algorithms from all the techniques and concepts learned to solve very diverse problems.

  • Design Patterns: Elements of Reusable Object-Oriented Software, 1st Edition: This is the original book on object-oriented design patterns. There are other more accessible books to read for this topic, but this is a classic. I don't mind if you replace this book with another.

  • Clean Code: A Handbook of Agile Software Craftsmanship, 1st Edition: This book is the classic book that teaches software engineer how to write clean code. A lot of best practices in software engineering is derived from this book.

  • Java Concurrency in Practice, 1st Edition: As a software engineer, you need to understand concurrent programming. These days there are various great concurrency abstractions, but I believe everyone should know how to use low-level threads and locks.

  • The Architecture of Open Source Applications: This website features 4 volumes of books available to purchase or to read online for free. It's content focuses on over 75 case studies of widely used open-source projects often written by the creators of said project about the design decisions and the like that went into creating their popular projects. It is inspired by this statement: "Architects look at thousands of buildings during their training, and study critiques of those buildings written by masters."

  • Patterns of Enterprise Application Architecture, 1st Edition: This is a good read to start learning how to architect large applications.

    The general theme of this list of books is to teach a hierarchy of abstract solutions, techniques, patterns, heuristics, and advice which can be applied to all fields in software engineering to solve a wide variety of problems. I believe a great software engineer should never be blocked by the availability of tools. Tools come and go, so I hope software engineers have strong problem solving skills, trained in computer science theory, to be the person who can create the next big tools to solve their problems. Nonetheless, a software engineer should not reinvent the wheel by recreating solutions to well-solved problems, but I think a great software engineer can be the person to invent the wheel when problems are not well-solved by the industry.

    P.S. It's also a lot of fun being able to create the tools everyone uses; I had a lot of fun by implementing Promises and Futures for a programming language or writing my own implementation of Cassandra, a distributed database.
u/jonyeezy7 · 16 pointsr/AskProgramming

If you need to be neo to read code, then that code isn't written well.

Code is read by humans not machine.

So write code like a sentence.

I recommend you to read clean code by Uncle Bob. Something they don't really teach you in school.

u/savagehill · 16 pointsr/roguelikedev

I prefer Uncle Bob's view:

> It is well known that I prefer code that has few comments. I code by the principle that good code does not require many comments. Indeed, I have often suggested that every comment represents a failure to make the code self explanatory. I have advised programmers to consider comments as a last resort.

Other times he puts it more bluntly:

>Comments are always failures. We must have them because we cannot always figure out how to express ourselves without them, but their use is not a cause for celebration.


>"Every time you write a comment, you should grimace and feel the failure of your ability of expression."

I know it's not always practical, but I like Uncle Bob's extremely demanding perspective, because I feel it sets a really high bar and struggling to work toward it is something that stretches me.

If this is a wildly shocking view, I highly recommend picking up a copy of Uncle Bob's book Clean Code which I learned about from this IRDC talk. I saw that talk, bought the book, read it, and my views were changed. I now refactor a lot more and comment a lot less.

Uncle Bob's minimally commented code doesn't come cheap though, he spends a ton of cycles after the code works, retooling it specifically to make it readable.

Also, for the record, I ain't no Uncle Bob. Don't misunderstand me as saying I live up to his standards please!!

u/therookie001 · 14 pointsr/cscareerquestions
u/igeligel · 13 pointsr/de

Kauf dir das Buch: oder lass es dir zu weihnachten schenken :)

Ansonsten: Wenn du schon einigermaßen was kannst guck dich mal auf github um, da gibt es zum Teil viele Projekte wo issues für Anfänger gelistet sind bei denen man relativ einfach in ein großes Projekt findet.

u/scandii · 13 pointsr/AskProgramming

as a beginner you're stuck in a position where you want to learn how to do things, but also how to write them. i.e you don't only want to paint a painting, but you also want it to be pretty and admired.

for programming there's a lot of schools of thought on this subject, some guys prefer test-driven development, others domain-driven design.

some think comments outside of method parameters are good coding praxis, others think it's a code-smell because if you have to explain your code you probably wrote it in a way that makes it difficult to understand.

some think patterns are for hipsters, others are of the correct opinion (ahem) that they are standardised solutions for common problems.

all in all, if I could go back in time 15 years when I started programming, I would read the following if they were available at the time:

Domain-Driven Design is the concept of breaking your code into logical real world units and bundling your code around these objects so that it makes sense to program if you understand the real world your program is mirroring. i.e if you're making a fruit shop program, you might have a fruit seller, a register, a fruit warehouse, a process to deal with ordering fruit etc.

Clean code talks not so much about the architectural patterns (outside of test-driven development) but rather what's good and bad about code at it's core. i.e

if(fruitStand.Amount < 5)
fruitHelper(fruitStand, 3434)


if(fruitStand.Amount < dailySoldAverage)
OrderNewFruit(fruitStand, wholesaleDiscountCode)

outside of that, I think you'll find a lot more resources by simply researching the concepts these guys talk about. programming is constantly changing, as long as you have the fundamentals in place as these guys talk about you're golden as long as you're willing to learn.

u/johnnydsick · 13 pointsr/csharp

I really enjoyed the C# Player's Guide. There's a newer version now but this is what I got.

Edit: I'm glad you guys liked this book as much as I did. To OP, I would offer two more suggestions.

  1. Clean Code This book is NOT specific to C#. However, it gives you a holistic understanding of how to write code that is readable and effective. This is how I was able to transition from writing code that simply functioned (primarily for school) to code that my coworkers could pick up and run with. The book is the bible of software style where I work.

  2. C# and the .NET Framework This is a very optional book in my opinion. It is also a little pricy, very long, more intermediate than beginner and you can gather much of its information from MSDN. However, I prefer looking things up and reading them in a book where possible. I also like having all this information in one location. When I have free time at work, I find myself more likely to flip to an unread section and skim over it than I would with the same information online.
u/sanity · 13 pointsr/MachineLearning

I recommend this book: Clean Code

We gave it to every new data scientist we hired at my last company.

u/Sorten · 12 pointsr/learnprogramming

I've heard this book discussed before; perhaps you would be interested in it?

u/frenchst · 12 pointsr/cscareerquestions

Three CS fundamental books in the order I'd suggest someone read them if they don't have a background in CS.

u/Eshakez_ · 12 pointsr/ruby

Clean Code is a great resource that touches on this topic and several other coding conventions.

Uncle Bob (the author of Clean Code) recommends that you organize your methods based on the context and the level of clarity. He would suggest putting the high level code near the top with the smaller helper methods near the bottom.

It compares a class to a newspaper. In a newpaper, you generally have the Subject at the top, with a high level description of the events that have taken place. As you read down the page, the articles will change from high level descriptions to low level details of the events.

Obviously, there are sometimes exceptions to this suggested rule.

TLDR: I wouldn't organize methods alphabetically. I would organize them logically from high level to low level.

u/Reptilian_Overlords · 12 pointsr/talesfromtechsupport

I'd go read books about the A+ cert (you don't need to certify but it's great material).

For other technical things I recommend a lot of books that are amazing:

u/Duraz0rz · 12 pointsr/learnprogramming

There's a book called Clean Code that may interest you. I have it and still need to read through it, but it's been recommended countless times on here.

u/brianbrennan · 12 pointsr/webdev

I think this article is great. Writing good maintainable code is a must for those that want to advance with their career. I'd suggest Clean Code to those that want to get better at this. Note that this is not a fun book, the first chapter even goes into detail saying how it's going to be a slog to get through. Other things to do are submit code for regular review, try and work with others as much as possible since it will make you much better at programming, and take your time doing things the right way, rather than the fast way. Speed comes later.

u/Scott90 · 11 pointsr/cscareerquestions

I think it would be good for you to read Clean Code. The things you dismiss as unimportant are in reality super important to make for a codebase that lasts longer than a couple of months.

Good, accessible code does not contain spelling errors. A 500-line class is too long. At my work, even things like //This method does x usually get a comment saying "missing space between after //".

Yesterday, we merged in a PR that had been open for 2 days and had 76 comments on it (that, admittedly, was too much, but it goes to show that the details matter, even in large PRs). Reviewing again after incorporating code review feedback is just as important because it's brand new code that others will have to approve.

Also agree with /u/batsam that we try to keep our PRs small so it makes it easy to review.

u/GoldFrame · 11 pointsr/learnprogramming

This book:

It helped me not to feel bad when I couldn't understand somebody else's code, since it could very well be designed poorly (I was struggling for weeks at work trying to rewrite a program, my mental leap occurred when I realised I was looking at spaghetti code all along). And that coding is like an art form, it communicates an idea to the reader.

u/hattivat · 11 pointsr/datascience


step 1: Read

step 2: Read and

step 3: Write a REST API which takes arguments from the URL, uses these arguments to run some predictive model of your creation, and then returns the result; since you already know Python, I'd recommend using Flask, there are many free tutorials, just google it. If using Python, I highly recommend using PyCharm (the free community edition is enough) over Jupyter or Anaconda, the latter will let you do many bad things which would trigger a red warning in PyCharm (such us doing import in the middle of the file).

step 4 (optional, but recommended): Learn the basics of Java (this tutorial should be more than enough ) and read

step 5: Write a publisher application which reads a csv, xml, or json file from disk (for bonus points: from someone else's public REST API for data, for example ), and turns the data contained within into a list of python dictionaries or serializable objects (btw, read up on serializing, it's important), and then sends the results into a kafka or rabbitMQ queue. I would strongly recommend sending each item/record as a separate queue message instead of sending them all as one huge message.

step 6: Learn how to use cron (for bonus points: Airflow) to make the application from step 5 automatically run every second day at 8 am

step 7: read the closest thing in existence to being the data engineering book:

step 8: Write a consumer application which runs 24/7 awaiting for something to appear in the queue, and when it does, it calls your rest api from step 2 using the data received from the queue, adds the returned result (predicted price, or whatever) to the data, then runs some validation / cleaning on the data, and saves it in some database (SQLite is the easiest to have running on your local computer) using an ORM (such as SQLalchemy).

step 9: Add error handling - your applications should not crash if they encounter a data-related exception (TypeError, IndexError, etc.) but instead write it to a log file (as a minimum, print it to the console) and continue running. External problems (connection to the database, for example) should trigger a retry - sleep(1) - retry cycle, and after let's say 5 retries if it's still dead, only then the application should crash.

step 10: For bonus points, add process monitoring - every time your application processes a piece of data, record what category it was in a timeseries database, such as influxdb. Install grafana and connect it to inlfuxdb to make a pretty real-time dashboard of your system in action. Whenever your application encounters a problem, record that in influxdb as well. Set grafana to send you an email alert whenever it records more than 10 errors in a minute.

Step 11: More bonus points, add caching to your application from step 2, preferably in Redis (there are libraries with helpful decorators for that, e.g. )

I'm assuming you are familiar with Spark, if not, then add that to your learning list. A recommended intro project would be to run some aggregation on a big dataset and record the results into a dedicated database table allowing for fast and easy lookup (typical batch computing task). You could also rewrite the applications from points 5 and/or 8 to use spark streaming.

I also heavily recommend learning how to use docker and kubernetes (minikube for local development), this is not only super useful professionally, but also makes it much easier to do stuff such as running spark and airflow on your home computer - downloading and running docker images is way easier than installing any of those from scratch the traditional way.

One crucial advice I can give is the mindset difference between data science and data engineering - unlike in data science, in data engineering you normally want to divide the process into as small units as possible - the ideal is to be processing just one [document / record / whatever word is appropriate to describe an atomic unit of your data] at a time. You of course process thousands of them per second, but each should be a separate full "cycle" of the system. This minimizes the impact of any crashes/problems and maximizes easy scalability¹. That is of course assuming that the aim is to do some sort of ETL, if you are running batch aggregations then that is of course not atomic.

¹ As an example, if your application from step 5 loaded all the data as one queue message, then the step 8 application would have to process it all in some giant loop, so to parallelize it you would have to get into multi-threaded programming, and trust me - you don't want that if you can avoid it (a great humorous tale on the topic ). You also have to run it all under one process, so you can't easily spread across multiple machines, and there is a risk that one error will crash the whole thing. If on the other hand you divide the data into the tiniest possible batches - just one item per message, then it's a breeze to scale it - all you need to do is to run more copies of the exact same application consuming from the same queue (queue systems support this use case very well, don't worry). Want to use all 8 CPU cores? Just run 8 instances of the consumer application. Have 3 machines sitting idle that you could use? Run a few instances of the application on each, no problem. Want the results really fast? Use serverless to run as many instances of your app as you have chunks of data and thus complete the job in an instant. One record unexpectedly had a string "it's secret!" in a float-only field and it made your app crash? No problem, you only lost that one record, the rest of your data is safe. Then you can sit back and watch your application work just fine while the colleague who decided to use multi-threading for his part is on his fifth day of overtime trying to debug it.

u/nutrecht · 11 pointsr/learnprogramming

> My code works, but if I was in a professional team, would they allow 5 nested if statements?

Probably not. I can strongly recommend reading the Clean Code book, it deals with a ton of these kinds of questions. And not just read it; apply what you read too.

u/localheinz · 11 pointsr/PHP

If upgrading your application from Yii1 to Yii2 requires a rewrite, then switching to Laravel or Symfony will also require a rewrite.

If you have read Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, then you might remember the Grand Redesign in the Sky - if not, take a look at What is Clean Code?:

> The Grand Redesign in the Sky
>Eventually the team rebels. They inform management that they cannot continue to develop in this odious code base. They demand a redesign. Management does not want to expend the resources on a whole new redesign of the project, but they cannot deny that productivity is terrible. Eventually they bend to the demands of the developers and authorize the grand redesign in the sky.
>A new tiger team is selected. Everyone wants to be on this team because it's a green-field project. They get to start over and create something truly beautiful. But only the best and brightest are chosen for the tiger team. Everyone else must continue to maintain the current system.
>Now the two teams are in a race. The tiger team must build a new system that does everything that the old system does. Not only that, they have to keep up with the changes that are continuously being made to the old system. Management will not replace the old system until the new system can do everything that the old system does.
>This race can go on for a very long time. I've seen it take 10 years. And by the time it's done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it's such a mess.
>If you have experienced even one small part of the story I just told, then you already know that spending time keeping your code clean is not just cost effective; it's a matter of professional survival.

Unless you and the team you work with has already asked and answered these questions, maybe there are more interesting questions to ask, for example:

  • What are the actual costs of a rewrite?
  • What is the business value of rewriting the application?
  • Perhaps the business is better off improving the current system than rewriting it entirely?
  • What can we learn about coupling our application to frameworks from this situation?
u/iprobablydisagree · 11 pointsr/programming

You should read Clean Code.

u/robertwilliams · 11 pointsr/cscareerquestions

You were showing off. I probably would have hung up as well.

The best code is boring. It just reads like prose. And it's tremendously difficult to write.

I am an architect / dev lead. I read a lot of code that others wrote. I don't want to spend any brain cycles parsing your code; I need to be able to focus on what you are doing and what the overall design is.

We have one developer here who apparently gets a bonus every time he uses the ternary operator. He likes to nest them as well as AND and OR his conditions.

return cond1 && cond2 ? val1 : !cond1 && cond3 || cond2 ? val2 : val 3

Very cute, but utterly unreadable.

My advice to you is to read the following books:

u/bot_bot_bot · 10 pointsr/learnprogramming
u/kotojo · 10 pointsr/IAmA

I'm just two months into my first real job for programming and have a few books I've been going through.

Clean Code is a book not just about writing code, but good code that is easily maintained and passed down to other people to understand.

Working Effectively with Legacy Code was a great read coming into company that has been around for 20 years and is on the third iteration of their product.

I am doing web development so You don't know JS, Javascript: the good parts and then Javascript The Definitive Guide have all been a great help.

If you aren't much a book person, is awesome for info on tons of different technologies and is well worth the monthly cost. Go follow every major name in your preferred technologies on twitter. They will tweet all sorts of cool things to learn about. Also, PODCASTS!!!. I don't even listen to music anymore. If I'm in the car alone I'll be listening to Dot Net Rocks or Javascript Jabber.

Lastly, there are subreddits for every tech imaginable. Go subscribe to them and hit everyone up for where they get all their info!

u/Medicalizawhat · 10 pointsr/learnprogramming

Well I left school in 10th grade, travelled around and worked odd jobs for most of my 20's until one day while working a particularly shitty job I realized if I didn't make a change soon I'd be doing jobs like that for the rest of my life! So I went to university and studied something unrelated for a few years. Somewhere along the line I clicked a link on Reddit that said "Try Ruby!" and it took me to a site kindof like Code Academy with a tutorial for Ruby. I tried it out, got instantly hooked and started spending all my free time programming!

Eventually it got to the point where programming all the time made me fail a few units so I dropped out of uni. I enrolled in a programming course but that didn't work out either, so I decided to take six months and just teach myself programming full time. It was a really awesome time, I'd wake up every morning and work on my projects, take online courses and read programming books all day!

Eventually I started running out of money. I didn't think I was good enough yet but the fact that I was rapidly becoming destitute gave me the kick I needed to start applying for jobs. I was incredibly lucky in the fact that I ended up getting hired at the first place I applied. Apparently they chose me over the other candidates because of my "life experience" and the projects on my Github, although the fact that I was willing to work for peanuts helped as well haha.

That was over six months ago and I'm still really enjoying it. If I were to offer some advice it would be to just stick with it. Even when you doubt that you are good enough, or smart enough, or that this whole learn programming idea might not work out at all and you'll never get a job - keep at it! If you enjoy programming and put the effort in then someone, somewhere will give you a chance, and all you need is one chance.

Also, make sure to take projects through to completion and post them on your Github. One simple, well written project is more valuable then 20 half finished ones. Code your projects knowing that your future employer will be reading it and deciding whether or not to hire you!

To that end, I'd highly recommend Clean Code. This book really helped me, but I'd recommend reading it after you've written a project of your own. Then, as you read through the book, go through and refactor your code.

Finally, when you're thinking of projects, don't worry about trying to create something amazing straight off the bat. Pick anything that interests you, maybe scratch an itch, or even re-implement something that already exists. At the end of the day the idea does't matter as much as the fact that you've spent the time and effort to build something. If you look at my projects, they're boring as anything! But they were good enough to get my foot in the door.

All the best!

u/SofaAssassin · 10 pointsr/cscareerquestions

> So something that would take in excess of 3 years to master is out, if you catch my drift.

You seem to be misguided on this point - while you can pick up the basics/fundamentals of programming pretty quickly, if you're so inclined, the actual practice of writing software, and writing it well, is going to take a lot of time investment. I look back at code/software I wrote when I was just starting out professionally, and while they worked, I know how poorly they compare to what I can write/design now.

Having 3 years of software development experience when starting from zero would probably leave you at 'junior' or 'mid' level at the end, and if you don't have a more experienced developer mentoring you throughout the process, you may be at a disadvantage. From the sound of it, your school has no actual programmers/developers.

With that said:

  • I would look at online resources to start out, like Learn X in Y Minutes or codecademy. Start playing around a lot and doing exercises.
  • For a beginner, a language like Python or Ruby tends to be easiest to start with, as they are simple to install and experiment with.
  • Additionally, learn about databases. MySQL and PostgreSQL are database systems that are widely used and free. Learn about database modeling, schema design, and how to actually write SQL.
  • Understand that pretty much anything you write or make in the first year or so that isn't very simple will probably be horrible hack jobs. You may not think they are, but trust me, they will probably have poor design, use nasty hacks, employ bad practices, and so forth. This is where on-going improvement is a necessity, and why people read books like Clean Code, The Pragmatic Programmer, and Code Complete.
  • Also, a mark of a good developer - assessing whether or not you have to actually write that code or software. I am not familiar with student management systems, but is it really going to be necessary to write your own, from scratch? Think of the following implications:
    • You are now your own support for your software - anyone in the school that has a problem with your app, you become the go-to person for fixing it or answering their questions, no matter how dumb the questions may be.
    • You become the point person for issues in the supporting system of the software - the database and the machines it runs on, primarily. You may be lucky enough to have IT helping you in this aspect, so hopefully you have an IT department that can do things like back up the database, maintain it, and restore it if something breaks.
    • Your software will likely be a hackjob - I do like to stress this point again, because none of us, starting out, turn out good software of moderate complexity without a couple years of experience. Time and time again I look at code written by fresh graduates or junior developers that are basically hacks or need a lot of cleanup/rewriting. Who will look over your code to tell you that?
    • Someone will have to maintain this software - and this will be you, but eventually, you might leave this job, so who will take over for you? Your school should be prepared for this eventuality.
u/sweml · 10 pointsr/compsci

Clean Code: A Handbook of Agile Software Craftsmanship it explains how to write elegant code in a simple and clear manner

u/tmakaro · 10 pointsr/physicsgifs

In my experience, most physicists write spaghetti code with no documentation that is a nightmare for others to work with, and even the original author of the code after not looking at it for a while.

While I don't think my code is that bad, I do think that I could have structured it to have fewer global variables by making better use of functions.

Here is a few quick tips for jupyter notebooks specifically. Here is a book on writing clean code. I would also recommend reading the python style guide (pep8 and pep257). I'd also highly recommend learning how to use a linter such as pycodestyle or pylint.

u/spoon16 · 9 pointsr/java

Clean Code

Code Complete 2

Both are great books. I just finished reading Clean Code and I highly recommend it.

u/threechewz · 9 pointsr/AskComputerScience

Well, there's the classic, Clean Code, which I haven't read but have seen recommended as a great book on this topic. But, in my opinion, as with anything else in programming, you get better by doing, and that includes writing better code. The more code you write the more you'll see basic patterns crop up and you'll start to realize what does and doesn't work. Does inheritance make sense here or should I use some type of composition. Is it worth refactoring this piece of code out to a more general abstraction. When I write, I try to have the mindset that someone else will be using my code in the future and I should write my code in a way that is as accessible for them as possible.

u/Sancty · 9 pointsr/javascript

Clean code... you can find it on amazon or anywhere else. Pretty highly regarded.


u/0b_101010 · 9 pointsr/learnprogramming

Hi! I recommend the following books:

u/chazzlabs · 9 pointsr/androiddev

> 5 - I've always struggled with this, anyone i talk to says comment your code, i just never see the use for me. ITs something im working on.

Clean Code: A Handbook of Agile Software Craftsmanship

Read that book, and start applying the techniques as you finish each chapter.

u/astronothing · 9 pointsr/Unity3D

Learn some design patterns:

Follow the SOLID principles:

Read "Clean Code" (and everything else by Robert C. Martin):

u/tokyo7 · 9 pointsr/programming

No, it would be better to just raise the point in the next stand up meeting, perhaps get a senior dev to sit with you while you figure out why the crap was written originally (Was it just a short cut?), whether it's needed any more or whether it should be re-written properly.

Once that decision has been made, the code and the horrendous comment can be removed or replaced by a more suitable solution.

We live in a modern age of modern source control, we do not need to leave messy large comment blocks all over our code.

I recommend the book 'Clean Code'

u/chanpod · 9 pointsr/cscareerquestions

Depends on what language or area you want to specialize in.

But the basics are important. Not so much being able to solve those stupid white board tests (I would not shoot for a company that does those as a self-taught first job individual. You'll just be discouraged. I've got 6 years experience and I doubt I could pass those stupid test without extensive studying.)

It's hard to say, b/c of some of it is...just exposure and your ability to think about abstract problems. I'm honestly not sure how to word it. But people who have had to go through academic training. EG Algorithms, data structures, modeling, etc... seem to just have a better understanding of abstract processes (if that makes sense).

Some things I feel are personally important.

Clean Code: Believe this is the one. I've never read it page by page but we had one college professor who basically taught the concepts from it.

Ability to actually talk about what it is you've done and know. The best way to do this is to have actually tackled a complex problem or project. Even if you need to make one up, you'll learn a lot. Things like properly structuring objects. Data flow. Singletons. Data storage. Security (if you're doing something web based). I personally built an entire website from the ground up. It included a content management system for the homepage. Custom permissions and a forum's section. I learned more from that personal project than I have from work honestly. It's now trashed in Github somewhere, but that wasn't the point.

Abstraction abstraction abstraction. This kind of goes with the clean code point.

Knowing the importance of testing. Difference between unit and e2e (if you're doing web). Some companies don't even write test so your mileage may vary on this one. Usually they still pretend like they do in the application and interview. But once you get in, they'll have zero test. And this isn't the worst if the application isn't very large or complex. There's a lot more to test but unless you're applying for that kind of position, it may not be as important. But being able to talk to some of the basics is good. (Like knowing some terminology. Black box testing, smoke testing, uhh, drawing blank on the can tell what jobs I've had sigh...)

I would say the tl;dr is...actually make something. And not something simple. And do it right. This will give you a lot of things to learn and think about and discuss in an interview. It'll make you more engaged and willing to learn. And most importantly, it'll demonstrate you can actually do what you say you can.

u/Omnicrola · 8 pointsr/java

I'm surprised nobody has recommended Clean Code by Robert Martin, which has good advice for keeping code clean in any language. Examples are given in Java. It echoes a lot of the advice given here, as well as explaining the reasoning behind the practices.

u/kyleaisho · 8 pointsr/learnprogramming

The goldilocks zone is needing 0 comments in order to easily read your code. Chose variable names and function names which are so obvious they don't need comments. However you'll eventually need comments as well, so a simple terse comment that describes only exactly what is being done is beneficial.

When you get enough programming under your belt check out this book:

u/fesor · 8 pointsr/PHP
u/enteleform · 8 pointsr/compsci

I've been coding for a few years and for a while was just focused on getting things to work.  Now I'm at a point where I know I'll figure out any given problem with my accumulated knowledge and/or additional research, and I'm noticing that not planning ahead is the most significant (lack of) action that will set me back at this stage in my practice.

To remedy this, I've been looking into architectural patterns (MVC, MVP, MVVM, etc.), and UML diagramming.


Architectural patterns were initially difficult to grasp, as many of the explanations available online dig into topics that might not make sense yet if you are inexperienced with architecture.  The MVC Java Tutorial by Derek Banas is the best introductory explanation of architectural patterns that I've come across (he also has some great videos on design patterns & other topics).
Some books that cover code structure & architecture in more detail:

  • Clean Code: A Handbook of Agile Software Craftsmanship

  • Code Complete: A Practical Handbook of Software Construction

    The author of Clean Code, Bob Martin, has a ton of talks that are a great source of info, and has also produced the CleanCoders series.


    Also check out some Software UML Examples.  I find that mapping out an overhead view of your project before starting to code gives you a chance to make sure the majority of relationships, life-cycles, and high-level details are planned out correctly from the start.  You'll still have to make inevitable adjustments while coding, but it's much more efficient than figuring it all out from the inside while you're building it.
    yEd Graph Editor is a good freeware option for creating UML diagrams.
    If you find that you really like the UML approach, check out Enterprise Architect.  It's definitely worth picking up since it allows you to generate file structures from your UML diagrams, with all of the boilerplate filled out already (class/method/variable definitions, etc.).


    Also related, SourceMaking has some good wikis on:

  • Design Patterns

  • Refactoring

  • Anti-Patterns

  • UML

    (Although their UML material is pretty in-depth and may be overkill if you just want to use UML as a quick way to plan out code.  But it's legit if you want to go all-out UML mode)
u/lmouelle · 8 pointsr/learnprogramming

Clean code. read it learn it love it

u/TransFattyAcid · 8 pointsr/webdev

The agile principles are based around the idea of iterative development. This invites what you're calling rework to make the product the best it can be.

Obviously, you're coming at this from a place of frustration because you want to meet deadlines but the "simple" solution is to build all these steps into your estimates. If you're not setting the deadlines, then you need to be up front with your manager about what you can get done in the given time. Maybe it'll work, but not be clean code (the P.S. here is that after it ships, you need time to make it clean). Maybe you can get features X and Y done, but not Z.

Refactoring and code reviews are part of the job. Yes, your manager is going to make suggestions you might not agree with and, yes, the senior devs are going to send you back to the drawing board sometimes. Sometimes it's because they're jerks and sometimes it's because experience has taught them something.

All in all, I'd recommend reading any of the following by Robert Martin. Clean Coder is perhaps most relevant to estimates and deadlines but they're all really helpful.

u/SolenoidSoldier · 8 pointsr/ProgrammerHumor

If you're interested, check out Clean Code. There is a chapter on just this. Put simply, you shouldn't be afraid to add length to your variable names, so long as they can concisely describe their function. I know, easier said than done, but it's helped steer me away from using acronym and single-letter variable names.

u/juliob · 7 pointsr/Python

Can I offer some food for thought?

On Clean Code, Robert C Martim said that functions should have, at most, 5 parameters. After that, it's a mess.

You should probably look into ways of reducing the number of parameters. Maybe 3 or 5 of those are related to a single object, with related functions.

Just a suggestion.

PS: Also, I think you'll get a Pylint error about too many instance variables, or something like that.

u/planetstarbucks · 7 pointsr/javascript

Buy Clean Code ( This book is my bible. Read it through once quickly, and refer back to it once in awhile, and I can guarantee you'll never write spaghetti code again.

u/lotion_booger · 7 pointsr/compsci

Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin, amazon link on the [internet] (

u/TheOssuary · 7 pointsr/PHP

I've been reading Clean Code: A Handbook of Agile Software Craftsmanship and chapter two discusses this, and agrees with you. Interfaces should not be suffixed with 'interface', and if you run into naming issues (wanting to name the interface and the class Product) you should lean towards naming the interface Product and the class ConcreteProduct.

I started following this practice and it makes a lot of sense after you start working this way. If I'm making an interface it means anything which implements it should be valid, so I should never type-hint a concrete implementation, I should only ever type-hint the interface. Adding the Interface suffix is just adding verbosity and possible confusion.

u/DevIceMan · 7 pointsr/cscareerquestions

> there is no documentation

Documentation typically, at best, describes only what the original author originally intended, and as you noticed, can become quickly obsolete.

Instead, another approach is to write cleaner "self documenting" code, which includes several concepts such as meaningful/descriptive names, single purpose principle, and several others. If you are interested in these concepts, I highly recommend "Clean Code" by Robert Martin.

> 30+ character length method names

Long names are not always always terrible; the more important question is are the names meaningful and descriptive? I recently worked at a place, where class and method names were of similar length to what you describe, and was originally extremely annoyed at the length. After reading the previously mentioned book, I was no longer annoyed at the length, but realized what bothered me the most was that the names were terrible and confusing, the code was poorly formatted, and the names had to be long because of excessive violation of single purpose principle.

Long names can make code easier or more difficult to read. Again, read Clean Code, and you'll have a better understanding and be able to better articulate what is wrong (and perhaps even fix it).

> There's water cooler talk about a method that's over 2,000 lines long.

Definitely a code-smell. My guess is the 130-char name, and 2000 line method violate single purpose principle quite heavily.

> My job: dead code removal.

Entry/Intern level jobs tend to be mundane grunt work that no one else wants to do. I'm not saying that to make you feel better, but rather so that you'll understand "why."

> When we do our daily scrum nobody even understands what I'm doing

Is your team almost purely interns?

> All our tests are broken now. All of them. Production is halted. Why? An execution script needed to have a flag added to it, the commit was made from a Windows machine, and now it's sitting on the trunk of our repo being deployed to all of our testing environments.

Code review and testing failure, especially given you're an intern. Your next paragraph seems to indicate your interaction with the "thing" somehow was part of a process that caused everything to break (though it wasn't specifically you that broke it)?

> What do I do?

5 years from now, it won't matter. The stress you are experiencing is not healthy, and will matter 5 years from now. Relax, stop stressing, the worst they can do is fire you... which is probably not a terrible thing and unless you're hurting financially. Go home on time, work at a consistent pace, and take care of yourself. Polish your resume, and find another company that is more sensible to intern at.

u/hubilation · 6 pointsr/ProgrammerHumor

That's exactly how you should code. Uncle Bob taught us that.

Uncle Bob is love, Uncle Bob is life.

Read his book

u/strcrssd · 6 pointsr/java

Read and adhere to the guidelines presented in "Clean Code" by Robert Martin (Uncle Bob). The book could have been written as a response to this question.

Edit: krogger pointed out I misattributed the work. This has been corrected. Thanks Krogger.

u/IRLeif · 6 pointsr/learnprogramming

Looks like most of your knowledge and experience so far is with imperative/object-oriented programming. You might want to have a look at functional programming, just to get some perspective. Scala, Erlang or Haskell could be some good choices here, or even Ruby (if you make use of blocks and don't use mutable data). Actually, Ruby is pretty cool and very versatile and practical, that could be a good language choice as well, and you would also be able to make use of your prior knowledge with OO programming.

One other thing that you could do with this time is to read some books! There are some wonderful "generic" titles that every programmer should read, in my opinion. Have a look at The Pragmatic Programmer, Clean Code and Code Complete, for starters. These might get you really inspired and pumped up for the undergrad college and computer science classes, as well as give you some good tips on new things to learn.

u/slowfly1st · 6 pointsr/javahelp

Since it's only a few weeks and you will use Java primarily, probably look primarily at the Java API's / components:

(honestly can't find this overview page for newer versions java)

Collections-API is a good start (Map, List, Collection and so on and their implementations), I/O (read and write files), Concurrency/Multithreading (also understand the concepts), JDBC (connect to a database, read and write data). Date/Time-API. Probably networking.

Also learn all the language features. E.g. that there are three different kind of comments, know "all the keywords" (what's volatile and transient? I always mix them up ...), or what is try-with-resource?

If you're decent with java, you'll have,... let's say "one problem less"


Learn OOP/OOD: Read and understand those concepts is a good start: SOLID, Loose coupling, High cohesion, Information Hiding. Those concepts we do apply, so we can reuse parts of our code (so it's not duplicated), improve maintainability, interchangeability (like changing the front end technology to display the website without redoing the whole software), and so on. Not sure if that's too early for you, in the sense, that you are still learning the language and learning another "thing" is too much.


Databases are already mentioned (many applications use a relational database as 'backend'): Setup a database (e.g. postgreSQL or mysql, both are free), learn how to create tables (columns, datatypes, primary keys, [indices, constraints]), crud operations (create, read, update, delete data), how to restrict selection of data (where clause), how "to join tables", functions (max(), avg(), count()). Imo the basic concepts of 'relational databases' and how you get/change data is quite easy compared to learning a programming language.


Read Clean Code. (Probably too early for you, but I leave it here)


Probably have a look at HTML/CSS/JS. I really like w3schools, but mostly as a reference, because I don't know these by heart. Not sure if you have enough time, but try to learn some of the components of html and learn how to style them. It's actually quite easy compared to Java. If there's enough time, to learn some JavaScript may be helpful, too.


... and now combine everything :P - no, seriously: "Ship" a product - even if it's something small and irrelevant. To break down a problem into smaller problems and combine everything we know to solve those problems with the most elegant solution is what we do day in day out. And get your code reviews (e.g. here on reddit, the stackexchange-network has a good code review network, too). Because there's always a better and more elegant solution. If no one tells you, your code sucks (... or can be improved) and why, you keep writing bad code - or at least you won't improve as fast.

u/chapmbk · 6 pointsr/java

The most important thing when looking for a Java developer job is to actually understand Java. I don't mean knowing how to write code in Java. I mean knowing how the language works. What is the purpose of equals/hashCode, how to make object Immutable, what is the String pool, etc...
You would be surprised how many developers think they understand the language and have no clue how it works.

  1. Read and understand effective java and clean code.
  2. Be familiar with and excited about automated testing. You should aim for 80% - 90% unit test code coverage in your projects.
  3. Be familiar with static code analysis tools. PMD, FindBugs, etc...
  4. Understand the benefits of code reviews. Be familiar with popular code review tools. Crucible, etc...
  5. Have a degree.
  6. Be familiar with current technologies. Show that you research new technologies on your own

    You do not need all these things to get a job. There are plenty of large IT organizations that will just hire lots of people to fill seats and then drop them if they don't work out. However, if you want to get a job at a company that is serious about producing quality code, you need to show that you are serious about being the best developer you can be. Getting a job at an organization like this will not only pay better but you will also have the opportunity to learn from all the highly skilled developers that work there.
u/Bibdy · 6 pointsr/gamedev

Alright, in that case it sounds like you can benefit from 'the general advice':

  1. Make a 'vertical slice' of the game as early as possible. Networking, animation, scene loading, GUI, etc. This will ensure that every major library and tool you need gets in there early, and you workaround the conflicts between them before it becomes a burden to insert a new one. One of the big mistakes on one an early projects was to leave the entire GUI to the last minute, but because that 'conflicts' with general user input it was a huge chore to workaround certain issues after a lot of the user input code was in place.

  2. Trello is a handy tool for managing tasks, but I'm sure there are other perfectly good alternatives. Despite what you use, update your task list often and make sure you break things down into bite-size chunks that can be accomplished within between an hour or an entire day. That way you're always making progress and keeping your motivation up as that list gets shorter (although it will inevitably keep getting bigger as you break things down more, or remember things you forgot originally)

  3. If its taking forever and motivation is going down the tubes, cut features. Don't debate, don't haggle, just start cutting features to trim down the workload and get yourself back on track.

  4. Source control. Use it. Git with Bitbucket, or TortoiseSVN and VisualSVN Server Manager are my go-to solutions. It's both a log of your activity and your only saviour when things go wrong.

  5. Don't be afraid to tell people about your project, and never tell yourself someone is going to steal your idea, because you need as much feedback as you can get. And the earlier the better. My wife asked me why I'm so cavalier about telling people about my current project even though I'm only a couple of weeks into it, and its because everyone has their own project that they believe in, and when I mention my project to someone they're more likely to give advice on how to make mine better, or more like their own project (unconsciously giving away their own 'secret sauce' recipe), than they are to steal it and build out a competing product. People will only bother stealing an idea that's already been proven to work.

  6. Read books on game development and clean coding practices (if you haven't already). You'll be amazed what great lessons people are willing to impart for next to nothing, or even free (like I'm doing for you right now, incidentally). Two of my favourites are Game Coding Complete and Clean Code - A Handbook of Agile Software Craftsmanship.
u/NisusWettus · 6 pointsr/csharp

C# in Depth likely isn't what you need. That's more aimed at proficient coders that want to understand the nitty gritty/internals.

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) is very popular. Not specifically aimed at C# (a lot of the examples are Java) but it's guidelines about how to write clean code in general. The lessons carry over to all/most languages. That's probably more the sort of thing you want.

Robert C. Martin aka 'Uncle Bob' also has a few other books but I've not really looked into them. e.g. this one is focused on C# and looks decent based on a quick skim of the index but I've not read it:

Agile Principles, Patterns, and Practices in C# (Robert C. Martin)

u/ForeignStudentUS · 6 pointsr/greece, και παρες όσες περισσότερες δουλείες μπορείς. Βιβλια που μπορεις να διαβασεις:

Αν δεν ξέρεις κάτι google it. Η Ελλάδα έχει μεγάλες προοπτικές ανάπτυξης και πολύ καλό βιοτικό επίπεδο. Αν καταφέρεις και κάνεις κάτι μπορείς να βγάλεις καλά λεφτά κάνοντας εξαγωγές. Έχουμε υψηλό μορφωτικό επίπεδο σε συνδυασμό με το χαμηλό κόστος βιοτικού επιπέδου είναι θέμα χρόνου μέχρι να αρχίσουμε να εξάγουμε competitively priced τεχνολογία.

Αν εχεις ποιο συγκεκριμενη ερωτηση πες μου

u/philintheblanks · 6 pointsr/learnpython

That's an interesting pattern you have going on there. I don't know what kind of background you're coming from, but one of the nice things about Python is that, being dynamically typed, you can pass almost anything to a function at run-time.

What that means is, you can have a function like a spell that expects a character object, whether it's p1 or p2 is irrelevant. It holds the logic of how to access the object and alter the attributes. There's a LOT that goes into how you design that, but that's a thing that literal books have been written about.

So, as a brief example, you might do something like this:

def fire_spell(target):
target.spell_hits('fire', damage=2)
return target

class Character:
def init(self, name, health=10, mana=10, immunity=None): = name
self._health = health
self._mana = mana
self._spells = {
'fire': fire_spell

def health(self):
return self._health

def mana(self):
return self._mana

def cast_spell(name, target):
return self

def spellhits(self, type, damage=1):
if self.immunity == type:
return None
else: -= damage
return None

So let's break that down a bit:

fire_spell: Exists outside of the characters. I would probably put all my spells in a separate module, that way I can import them, and add and remove them at run-time from the characters. That enables you to do things like have spells that aren't accessible prior to a level up, or some other mechanic. This isn't too different from having a separate class for the moves, since you're trying to namespace the moves, but I'll get to where that's a little odd here in a second.

self._health: This is just an attribute, but note the leading underscore. This is a pythonic convention that tells anyone who is using your code not to use this variable to access the thing that it points to. That is it would be best to leave it private. Python doesn't have private variables, so this is as good as it gets. We're all adults here.

@property: This is an example of a built-in decorator. If you don't know what decorators are, there are TONS of tutorials out there. Essentially, they modify how a function works. This one makes it so that instead of having to call the function, e.g., you simply access it as an attribute a la Why on earth would you want to do this though? Well, any code in the function will run prior to returning the attribute! This allows you to modify what the calling code receives when it accesses the attribute. You want to have a conditional health buff based on the zone that the character is? Boom, way easier with this pattern. What to have the mana get dropped to 0 because of a status effect, easy peasy. And as soon as the effect clears, it can go right back to where it was! Basically, @property is really cool.

spell_hits: This is a method on the Character object. This you know. But why is it there? Well, designing a game is essentially designing an API. You may have heard of API around town, usually people are talking about web APIs, but the term is Application Program Interface. It applies equally to what this is. The Character class exposes an API to function inside of your program. They can expect that if they're going to receive a Character then they can act on it in a certain way. This is actually where you start to understand why certain programmers really aren't fans of dynamic typing. Python gives precisely 0 shits what you pass to this function. You can pass it a list of integers and it will not be annoyed. Well, until you try to call spell_hits. Then you get PropertyError: list object has no method 'spell_hits'. This won't happen until runtime. Then you're stuck chasing down which part of your gaht DANG CODE PASSED IN A DAMNED LIST!!!!! This probably won't happen to you with a small program, but I like to add context!

return self: Why would you do that? Well, we're back to the concept of API design! It's a pattern used for a "fluent interface". This pattern allows you to utilize method chaining, which is a really nifty thing. For example, let's assume that you want to run specific series of methods on a certain user input, then you could do p1.cast_spell(p2).use_item(p1).another_method(). This is a pattern that you see in a lot of libraries. It helps wrap your head around it if you write some code yourself that does it.

As far as your code is concerned, there's on thing that really sticks out:


You don't need to explicitly call __init__. The __init__ function is what a lot of pythonistas refer to as a "dunder method", short for "double-underscore". I prefer to call them "data-model methods", since that tells you what they're actually a part of, instead of describing how they're written (which is totally useless information). A bit pedantic? Totally, but I wouldn't be a programmer if I didn't have a pedantic pet peeve (how's that alliteration!)

Data model methods are called when they need to be, and in the case of __init__ that is when you initialize an object. Example:

class Thing:
def init(self, name): = name

t = Thing('bobby brown')

That will output 'bobby brown' because we assign the newly initialized Thing object to the variable t. Without capturing the object with a reference to a variable, they will be garbage collected. Basically, the Attributes and Moves objects that you're initializing will not be attached in any way to the player. You would need to do something like

self.attributes = Attributes(self)

Which would allow you to reference the new objects inside your player. Garbage collection in python isn't something that you'll need to be concerned about often, but I mention it because it's nice to know that python uses reference counting. Well, C Python does, and you're probably using that, so....

Overall, I think that what you need to get coded (pun intended) into your brain is the idea of frist class-ness, specifically as it relates to python. This concept is what makes decorators possible, and underlies the design patterns related to classes. I would also highly recommend the official tutorial as a place to find solid info on basics.

Past that, really it comes down to design choices. There's a million other ways than the one that I gave you to do this. Each one has a good reason to do it, and each one has trade-offs. This is where the rubber meets the road! Real programming boys! If you're interested in reading something that might help, I recommend Clean Code as a good read on designing good reusable software. The design book I linked above is kind of dense and uses Java, which could be confusing if you don't have experience with it. Clean Code is more generalized.

TL;DR: Functions accept objects, so pass the player object to the function and alter the health there. Then go read a LOT of stuff on OOP design patterns, cause they're hella hard.

u/yawpitch · 6 pointsr/learnpython

Just gonna say it; if you're not using function and/or class definitions in every file then you haven't learned Python or programming. Not yet.

Most of professional programming is maintaining code, usually in concert with others; you must be using factorization primitives -- in Python that's functions, classes, and modules -- to write code that is even testable, which is the start of being maintable.

I would suggest starting with a book like Clean Code.

u/mmmguitar · 6 pointsr/java

Like most time in my job, I dont have alot of time to look at code, so something I find important is how clean / understandable the code is and at a glance its where I'm struggling with your code.

In particular, process request seems to be 200 odd lines long, doing many things and branch / nests alot and to understand you have to delve in to the guts of it and also read comments (which on shared code will go out of date). I think the complexity would really show if you try to unit test the code.

Clean Code is an awesome book on the subject. At times may go over the top a little but the message is great.

So to break that method down and make it cleaner / more understandable you can do 2 things. Firstly, small private methods that self document:

For example in the middle of the method you do this with a comment:

//----- DATA SEPARATOR -----//
String delimiter = "\t";
if ((REQUEST.get("FILE_DELIMITER") != null) && (REQUEST.get("FILE_DELIMITER").length() > 0)) {
String sep = REQUEST.get("FILE_DELIMITER").trim();
if ("COMMA".equalsIgnoreCase(sep)){
delimiter = ",";
} else if ("PIPE".equalsIgnoreCase(sep)){
delimiter = "|";
} else /if ("TAB".equalsIgnoreCase(sep))/ {
delimiter = "\t";

could be extracted to this:

String delimeter = getDeliminator(request)


private String getDeliminator(Request request) {
if ((request.get("FILE_DELIMITER") != null)) {
String sep = REQUEST.get("FILE_DELIMITER").trim();
if ("COMMA".equalsIgnoreCase(sep))
return ",";
else if ("PIPE".equalsIgnoreCase(sep))
return "|";
return "/t"

The advantage with that extraction is now processRequest has got smaller and there is now 1 line saying get delimeter that I can understand straight away because the name of the method is saying what its doing. Because of that you don't need that commend and the code becomes self documenting.

Its also simpler because there is no longer variable being defined with a default value that may or may not get overriden.

The delimeter calculation logic is now wrapped up in a nice little method that does 1 thing. Ultimately processRequest doesnt care how the delimiter is calculated, just that it gets one.

Everything has got a little cleaner and simpler.

So yeah there's many places that that sort of extraction / self documentation will help. Generally speaking a method should do 1 thing, if its over 4 lines long then it may doing too much (ok that quite extreme, but long methods are a sign of methods may be doing too much)

The second thing that may help is breaking that class up a bit. Its doing a lot, processing request, generating a file, doing all sorts of things with processing, writing the file out.

If you break things up a little you can reduce the complexity of whats going on, i.e. process request process the request and leave it up to something else to do file generation etc.

Its handy because it greatly simplifies testing, you can then starting testing the individual components. More along the single responsibility type idea.

A couple of other quick things I noticed, only use CAPS variable names for static instances. You have dual variables request and REQUEST doing differrent things,, i dunnore, request and requestTable?

Theres also a couple playes where you are catching an exception and doing nothing, it supresses the exception, generally thats bad, at least do a stack trace or log the exception happened. Its hard tracking down bugs / odd behaviour when exceptions are suppressed.

u/tech-ninja · 6 pointsr/ProgrammerHumor

Depends what you want to learn. Some of my favorites are

  • Code by Charles Petzold if you want to know how your computer works under the hood.

  • Peopleware if you want to learn how to manage knowledge workers.

  • Clean Code by Uncle Bob if you want to learn about good practices and program structure. Impressive content, covers much more than I expected.

  • Don't Make Me Think if you want to learn about usability.

  • Algorithms by Robert Sedgewick if you want to learn about DS & algorithms.

  • The Art of UNIX Programming by Eric S. Raymond if you want to learn about the unix philosophy. Lots of hidden gems in there. Have you ever heard: write programs that do one thing and do it well; don't tune for speed until you've measured; imagine all this knowledge distilled to you in one book.

    This a good list to get you started :) most of my favorite books are not language specific.
u/joellarson · 6 pointsr/PHP

I've learned to enjoy writing similar to how Robert Martin outlines in his book, Clean Code

If I were to write this specific code by it, it would look something like this:

function retrieve_all_items_from_storage()
$result = DB::select("SELECT id, item, description, cost FROM items");

return $result;

function format_item(&$item) {
$item->item = "Hello " . $item->item;

function get_all_items()
$items = retrieve_all_items_from_storage();

if(empty($items)) {
return array();

foreach($items as $item) {

return $items;

However, I would never write my example into my own projects because there would be a lot more complexity to it. For instance, I would have the retrieve_all_items_from_storage implement a data mapper, and have it return a Collection object, where I would do $itemCollection->isEmpty() instead of empty($items). It would also be organized into a multiple classes because of the nature of the functions. So while this is not something I would condone in your software, I firmly believe it is almost always better to have your method names define what a block of code does, rather than jamming it all into a function and commenting it out.

-- Edit --

I seemed to have missed the original question. If I had to pick, I would say the second block of code for similar reasons to what I outlined above.

u/pootangina · 6 pointsr/minimalism

When you're working with other people, it's probably better to follow the code conventions set by the team or the company. That's for consistency and making your fellow programmers' lives easier.

Otherwise, I recommend you read Clean Code. You'll learn a lot about proper commenting, separation of logic into functions (Uncle Bob recommends short functions), and many more!

u/ultimape · 6 pointsr/learnprogramming

The Anti-Pattern###

What you've got here is similar to the "Arrow anti-pattern", but may also be part of the "Redneck conditional" anti-pattern. Its hard to tell without seeing the rest of the code.

Here's an article that covers the redneck pattern. It links to some great resources for fixing the Arrow issue at the end. This Youtube Presentation: The Clean Code Talks -- Inheritance, Polymorphism, & Testing and a pretty good overview on Coding Horror: [Flattening Arrow Code](

This Is Normal###

I end up with this pattern a lot on my first pass through prototyping a program. Sometimes its faster to write something quick and dirty - generating code as you think of it (redneck conditionals and all), then go back through and pull out redundancies and rework things to avoid !isTrue lines and other less than good code.

I think this has to do with how spoken language needs to be compiled into thought 'just-in-time'. We front-load our conditionals simply because the mind is not good at keeping more than a page full of words running at any given time. Its only natural to think about problems this way.

This is why languages like Perl and Scala appeal to me - it lets you say things like "do this thing, unless that" and sometimes feels like poetry.

Let it Haunt you at Night ###

Never be comfortable with code like this. Good developers strike a balance between writing good code, and shipping code.

Being a great programmer is 90% sweat, and another 90% discipline. Taking pride in your code means you don't release what you've written into the wild unless there is a good reason for it. If you can help it, don't let prototype code become production code. When in doubt, go with the mantra of "fuck it, ship it", but don't sweep bad code under the rug. Ignoring the problem of technical debt will come back to haunt you one way or another..

And remember: "Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live."

Why It Is Important To Fight It###

If there is never time (or demand) to clean up this awful code, all you end up doing is building up technical debt, eventually leading to the lavaflow antipattern and other more disastrous patterns.

My rule of thumb for keeping things DRY is the rule of three.

Do this enough, and in time you will start to see opportunities to rewrite your code as you do it. Basically you start to think like a programmer and metaphorically 'speak the language'.

What Happens When You Don't###

Fighting this way of programming is what elevates a good programmer to a great programmer.

The truth is that this is the default/naive style that comes out of procedural programming. You can become so good at this style of coding that you become an Expert Beginner

These expert Cowboy Coders look amazing to management. They able to sling code around fast and brute force their way through code like a mad man. Many 'expert' programmers, even ones who've been in the industry a long time, fall back on copy/pasting code so often that when they end up copying the same bug through out their codebase they don't even take a second thought. This style of development seen normal to them, and being riddled with bugs is just the cost of doing business.

Entire organizations can find themselves full of these types of programmers to the point that the culture shifts from wanting clean code to one that ends up being little more than a drawn out death spiral.

From my experience, this style of coding is very easy to do in languages like COBOL and FORTRAN and can be the default style in larger codebases that were minted before Structured Programming took hold. This lead to the often quoted line by Dijkstra: "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.".

This can lead to organizations shooting themselves in the foot and losing their best programmers. The codebase becomes riddled with bugs that seem to be near impossible to stamp out, and the ticket workload becomes so intense that you end up with the Crunch Time organizational anti-pattern just to fight the effects of technical debt. I can't see a self-respecting programmer lasting long in such an environment.


I've been trying to find organizations that are passionate about their code quality, and serious about their company culture. If you know of one, please let me know.

u/MINOSHI__ · 6 pointsr/computerscience

are you talking about this book ?

u/desrtfx · 5 pointsr/learnprogramming

Your friend is wrong. Sure, functions are for code reuse, but they should also be used to make code readable and especially to break down large chunks.

Just give your friend Clean Code by "Uncle Bob" Martin to read. It will completely change his views on code.


BTW: The second version of your code is way better, but why did you not go all the way? You still have the crossHairTexture stuff in the constructor. Why did you not also stick this part in a function?

u/caryy · 5 pointsr/learnprogramming

In addition to Code Complete 2, which, while very dense, is a compendium of wonderful coding knowledge... I recommend Clean Code by Robert C. Martin.

One of the best books on concurrency that I've ever read is definitely Java Concurrency In Practice it's (obviously) written with Java in mind, but most of the concepts map rather easily to constructs in other languages as well.

The standard for design patterns is still probably Design Patterns (colloquially "Gang of Four")... but I've heard good things about Head First Design Patterns as well, despite the really stupid cover.

u/cplusequals · 5 pointsr/politics

Currently reading Clean Code. Highly recommend it to any other software developers.

u/healydorf · 5 pointsr/cscareerquestions

Most undergraduate courses offer some sort of capstone or "Software Engineering" course which takes you through some flavor of SDLC from start to finish.

There's books you can buy on this specific topic -- buttloads of them.

> I feel like each one is a patchwork monster of code given life only by the grace of sheer determination and a bit of luck.

Check out Clean Code if you haven't.

u/OwlThinkAboutIt · 5 pointsr/learnprogramming

[here is a fantastic book every programmer should read] (

u/TracerBulletX · 5 pointsr/iOSProgramming

I spent a lot of time learning specific architectures and patterns that were in common usage when I first started, but the specific patterns in vogue are constantly changing. I'd recommend reading all 3 of these books at some point earlier in your career, I think a lot of the popular software design practices are based on the foundation of ideas in here and if you read them you will start to naturally make the right choices when it comes to organizing your code.

u/kraftvgs · 5 pointsr/javahelp

For the love of god find someone else that teaches Java at a high school level. Go over their lesson plans with them. Figure out what types of things they are teaching through each unit. While reading Head First is a good introduction to programming Java, it isn't necessarily what you need to be teaching these kids at this point.

Is this a first programming class for most? Or is this a follow-up to an introductory class? There are a lot of variables that will influence the content and concepts that should be taught.

Finally, and please don't take offense to to this, but I find it crazy that they are having someone with NO experience in the position of introducing people to a field that can be simultaneously fun, frustrating, rewarding, difficult, etc. Again, please don't take offense, but you will not do a good job grading as you have no experience. You need time to practice identifying good and bad code yourself. For every problem out there you can probably devise hundreds of ways to successfully solve it, but only some of them will be elegant and (hopefully in a teacher's eyes) acceptable.

For the love of god take a programming class! Have someone look at code you are writing because there is no better way to learn than to do it yourself. Head Start is a decent point to learn Java. Also check out Clean Code as it will help you learn some fundamentals of what makes good code. Finally, get together with another teacher that has experience teaching this subject matter and leech as much as you can off of them. Software programming can be a fun and very lucrative career. I understand you are lazy but please don't sour kids on it or start them off on the wrong foot.

u/mbizzle88 · 5 pointsr/learnprogramming

Most things can't be classified as universally bad style.

Getters and setters are appropriate for objects that act as data structures (i.e. objects that provide efficient storage of data without other behaviour). They're not appropriate for more complex objects that provide services (such as the BankAccount example given by /u/exoticmatter).

Static methods are useful for making utility or helper methods, among other things. (For example, it would be really wasteful to create a new object every time you wanted to print to the console.) They're generally discouraged in cases where polymorphism would lead to cleaner code.

In short, form follows function. If you're looking for a more in depth discussion of code style, I recommend checking out Robert C. Martin's Clean Code.

u/Mattyy_Westside · 5 pointsr/cscareerquestions

Clean Code is also a great book

u/ShadowWebDeveloper · 5 pointsr/cscareerquestions

> "oh yeah, that's just how that goes. If you run those one-off they always fail. You have to run the whole suite to make it work."




u/doubles07 · 5 pointsr/learnpython

The book Clean Code was recommended to me by my manager when I asked about writing more efficient code. The author goes through best conventions of naming/organizing/etc for keeping your code base super clean and legible. Other people also recommended the Pragmatic Programmer, but I haven't had time to get to it.

u/sh0rug0ru · 5 pointsr/java

Read lots of code and read books to get multiple viewpoints. This is a deep topic which will require more than superficial online reading.

Check this out.

Books I have found useful:

u/JonnyRocks · 5 pointsr/csharp

The most important thing to me isn't that someone knows everything about a language but knows how r o code well. I highly recommend - Clean Code: A Handbook of Agile Software Craftsmanship

u/Feroc · 5 pointsr/learnprogramming

I recommend the Clean Code book, it has easy examples for stuff like that.

u/endre86 · 5 pointsr/learnjava

That is a lousy professor. You want to learn more? Nope, don't think so.

You could find open source projects that are written in java. Or maybe check out the source code for OpenJDK (library implementation).

But better yet, pick up a book. You have the popular book Clean Code by R. C. Martin that covers how to write clean and maintainable code. Or maybe the book Head first: Design Patterns by that covers common designs used to make adaptable and reusable code.

But your professor has one point. You should not get lost into code design when still learning the basics. So remember to focus on what you learn in class! :)

u/srs_moonlight · 5 pointsr/cscareerquestions

I cannot recommend Clean Code by Uncle Bob nearly enough. I learned about him from his (rather idiosyncratic) videos on the subject, and it literally changed my outlook on writing software, top to bottom.

This might seem hyperbolic, but I can't stress the value of his ideas enough - my old company had access to his videos on our internal network, and the first 5-7 videos became required watching for the entire team I worked on. It was a lot of time to devote to something that wasn't coding, but I really believe it helped even new graduates understand the ideas behind "good code" and how to make clean systems in practice.

Let me know if you have any questions about the what or why of the suggestion.

Edit: In the spirit of PM_ME_UR_PIN_NO, I would also emphasize that there is no royal road to writing perfect code, because there isn't even consensus on what perfect code is. This kind of thing is the part of what we do that is more art than science, but I have yet to see a more effective collection of useful tactics than Uncle Bob's work.

u/thatsnotgravity · 5 pointsr/learnprogramming

Pragmatic Programmer, Clean Code, and Head First Design Patterns come to mind right away. They're 3 of my favorites.

There's also Design Patterns by the Gang of Four. That's a lot more dense IMO than Head First, but it's fantastic material.

Since you're looking to jump ship and start interviewing, take a look at Cracking the Coding Interview. That will prepare you for any questions you run into during the process.

It's probably also worth brushing up on Algorithms and Data structures.

u/wirther · 5 pointsr/learnprogramming

I actually never considered speed when thinking about best practice, so that's an interesting thing to keep in mind as well.

But yeah, one thing I forgot to mention is that I've been reading the book Clean Code, and so far, your solution fits in much better with the conception of best practice that I've learned from that book than all of the solutions voted best practice on codewars. Like I went into codewars thinking to minimize writing lines that do more than one thing, and to try to avoid cryptic syntax as much as possible, but that's the exact opposite of what codewars has been telling me is best practice so far.

u/Eligriv · 5 pointsr/learnprogramming

The trick is training as you go. Like 10-30min everyday, a morning routine before opening your emails, or something like that.

Choose an exercise (/r/dailyprogrammer or any code kata) and try resolving it during your timeboxed training session. At the end of the session, delete your code, and start again the next day.

Each time, focus on one aspect of the code : clean code, unit tests, object calisthenics, etc..

After a few times, when you can solve the problem with your eyes closed, pick a new one.

When you like what you did, put it on your github account and show it to other people (like on reddit or your lead dev etc)

Some resources :

u/periphrasistic · 5 pointsr/OSUOnlineCS

Hmm, I had a very different impression: I thought that Architecture & Assembly and Networks were the two best courses in the program, that Data Structures, Algorithms, and Operating Systems would have been among the best had they been taught a little better (for the former) or were more rigorous (for the latter), and that the Software Engineering courses, along with Web Development, Databases, and Mobile/Cloud were the worst courses in the program.

For SE I, the primary problem, as I saw it, was that the information was either badly out of date, or covered in such cursory depth as to be useless. The course is heavily based upon the optional textbook, and if you actually read the textbook, you'll quickly discover that the overwhelming majority of the research being cited and presented is from prior to 1990, and hardly any of the citations are from after 2000. Likewise, the course focuses heavily on software development process models, specifically Waterfall and Extreme Programming. However, neither process is particularly popular in the 2016 job market; most organizations at least nominally use some form of Agile methodology, but generally not particularly well. In any event, the process model used by your organization will likely be something you learn on the job. Finally, the course almost completely ignores issues of coding style and writing code that can be easily understood by other developers (which is an entirely different skill than writing code which will pass a grading script), and the sections on system design and object-orientation, which should be the heart of a software engineering course, are entirely cursory. SE I is sadly a required course, but if you actually want to learn software engineering, you are far, far better served by carefully reading Robert Martin's Agile Software Development and Clean Code.

The less said about SE II, the better. That course is a disorganized mess and OSU should honestly be ashamed to charge money for it (the bulk of the course content, in terms of lecture time, consists of links to two free Udacity courses).

u/mrthelight · 4 pointsr/cpp_questions

OK, I'm surprised that I'm the first to mention this. First, about some of the answers already given, as mentioned in Clean Code,

>You also don’t need to prefix member variables with m anymore. Your classes and functions should be small enough that you don’t need them.

I think it is better to not use convention such as `m
prefixes because this make your code less noisy, hence putting the emphasis on what you truly want to communicate. Of course, if doing this is a convention in the project you are working on, well, do it. It's probably not worth loosing your time fighting over this convention.<br /> <br /> Moreover, the idiom<br /> <br /> Foo::Foo(int fooCount): fooCount(fooCount)<br /> {}<br /> <br /> is perfectly OK. You can find a lot of references where people do this. However, as almost every rules, you cannot apply it blindly. For instance,<br /> <br /> Foo::Foo(std::vector&amp;lt;int&amp;gt; fooCounts): fooCounts(std::move(fooCounts)) {<br /> assert(fooCounts.size() &amp;gt; 0);<br /> }<br /> <br /> is a bug. There are two ways to solve it,<br /> <br /> Foo::Foo(std::vector&amp;lt;int&amp;gt; fooCounts): fooCounts(std::move(fooCounts)) {<br /> assert(this-&amp;gt;fooCounts.size() &amp;gt; 0);<br /> }<br /> <br /> and<br /> <br /> Foo::Foo(std::vector&amp;lt;int&amp;gt; fooCountsRhs): fooCounts(std::move(fooCountsRhs)) {<br /> assert(fooCounts.size() &amp;gt; 0);<br /> }<br /> <br /> <br /> I prefer the later, since it give the best result when you generalize it to setter, i.e.<br /> <br /> Foo&amp;amp; Foo::setFooCounts(std::vector&amp;lt;int&amp;gt; rhs) {<br /> fooCounts = std::move(rhs);<br /> return *this;<br /> }<br /> <br /> has the signatureFoo&amp; Foo::setFooCounts(std::vector&lt;int&gt; rhs)which is less noisy thanFoo&amp; Foo::setFooCounts(std::vector&lt;int&gt; fooCounts)wherefooCounts` is repeated twice on the same line.

In summary, the goal when you code is to communicate your intention in the best way you can, which implies giving enough, but not too much, details. In particular, you do not want to repeat yourself or to give information which is made obvious by the context.

u/spoonraker · 4 pointsr/personalfinance

Self-taught software engineer checking in to add on to this.

Everything u/TOM_BRADYS_PET_GOAT said is true.

I'll add a few specific resources:

Computer science fundamentals are really scary and overwhelming if you're self-taught. I'd highly recommend reading The Imposter's Handbook to get started with this topic. You'll want more in-depth material afterwards on each of the various subtopics, but this book is absolutely fantastic as a (surprisingly deep) introduction to all the concepts that's framed specifically to get self-taught programmers up to speed.

After you're familiar with the concepts at a conceptual level, and it's time to just get down to dedicated practice, Cracking the Coding Interview will be an invaluable resource. This book exists for the sole purpose of helping people become better at the types of questions most commonly asked during coding interviews. It's not just a list of a bunch of questions with solutions, it actually explains the theory in-depth, provides drill and smaller practice questions, as well as questions designed to emulate specific interview scenarios at real tech companies like Google, Microsoft, Amazon, etc. It'll even talk about the interview process at those companies outside of just the questions and theory behind them.

As a more general resource that you'll reach for repeatedly throughout your career, I'd recommend The Complete Software Developer's Career Guide. This book covers everything. How to learn, how to interview, how to negotiate salary, how to ask for raises, how to network, how to speak at conferences and prepare talks, how to build your personal brand, how to go into business for yourself if you want, etc. and that's just scratching the surface of what's covered in that book. I did't even buy this book until I was 10 years into my career and it's still very insightful.

And lets not forget, being a good developer isn't just a matter of making things that work, it's a matter of writing code that readable, extensible, and a pleasure for other developers to work on. So to this end, I'd recommend any developer read both Clean Code and Clean Architecture: A Craftsman's Guide to Software Structure and Design

u/CSMastermind · 4 pointsr/learnprogramming

I've posted this before but I'll repost it here:

Now in terms of the question that you ask in the title - this is what I recommend:

Job Interview Prep

  1. Cracking the Coding Interview: 189 Programming Questions and Solutions
  2. Programming Interviews Exposed: Coding Your Way Through the Interview
  3. Introduction to Algorithms
  4. The Algorithm Design Manual
  5. Effective Java
  6. Concurrent Programming in Java™: Design Principles and Pattern
  7. Modern Operating Systems
  8. Programming Pearls
  9. Discrete Mathematics for Computer Scientists

    Junior Software Engineer Reading List

    Read This First

  10. Pragmatic Thinking and Learning: Refactor Your Wetware


  11. Code Complete: A Practical Handbook of Software Construction
  12. Software Estimation: Demystifying the Black Art
  13. Software Engineering: A Practitioner's Approach
  14. Refactoring: Improving the Design of Existing Code
  15. Coder to Developer: Tools and Strategies for Delivering Your Software
  16. Perfect Software: And Other Illusions about Testing
  17. Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application

    Understanding Professional Software Environments

  18. Agile Software Development: The Cooperative Game
  19. Software Project Survival Guide
  20. The Best Software Writing I: Selected and Introduced by Joel Spolsky
  21. Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
  22. Rapid Development: Taming Wild Software Schedules
  23. Peopleware: Productive Projects and Teams


  24. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
  25. Against Method
  26. The Passionate Programmer: Creating a Remarkable Career in Software Development


  27. The Mythical Man-Month: Essays on Software Engineering
  28. Computing Calamities: Lessons Learned from Products, Projects, and Companies That Failed
  29. The Deadline: A Novel About Project Management

    Mid Level Software Engineer Reading List

    Read This First

  30. Personal Development for Smart People: The Conscious Pursuit of Personal Growth


  31. The Clean Coder: A Code of Conduct for Professional Programmers
  32. Clean Code: A Handbook of Agile Software Craftsmanship
  33. Solid Code
  34. Code Craft: The Practice of Writing Excellent Code
  35. Software Craftsmanship: The New Imperative
  36. Writing Solid Code

    Software Design

  37. Head First Design Patterns: A Brain-Friendly Guide
  38. Design Patterns: Elements of Reusable Object-Oriented Software
  39. Domain-Driven Design: Tackling Complexity in the Heart of Software
  40. Domain-Driven Design Distilled
  41. Design Patterns Explained: A New Perspective on Object-Oriented Design
  42. Design Patterns in C# - Even though this is specific to C# the pattern can be used in any OO language.
  43. Refactoring to Patterns

    Software Engineering Skill Sets

  44. Building Microservices: Designing Fine-Grained Systems
  45. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools
  46. NoEstimates: How To Measure Project Progress Without Estimating
  47. Object-Oriented Software Construction
  48. The Art of Software Testing
  49. Release It!: Design and Deploy Production-Ready Software
  50. Working Effectively with Legacy Code
  51. Test Driven Development: By Example


  52. Database System Concepts
  53. Database Management Systems
  54. Foundation for Object / Relational Databases: The Third Manifesto
  55. Refactoring Databases: Evolutionary Database Design
  56. Data Access Patterns: Database Interactions in Object-Oriented Applications

    User Experience

  57. Don't Make Me Think: A Common Sense Approach to Web Usability
  58. The Design of Everyday Things
  59. Programming Collective Intelligence: Building Smart Web 2.0 Applications
  60. User Interface Design for Programmers
  61. GUI Bloopers 2.0: Common User Interface Design Don'ts and Dos


  62. The Productive Programmer
  63. Extreme Programming Explained: Embrace Change
  64. Coders at Work: Reflections on the Craft of Programming
  65. Facts and Fallacies of Software Engineering


  66. Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
  67. New Turning Omnibus: 66 Excursions in Computer Science
  68. Hacker's Delight
  69. The Alchemist
  70. Masterminds of Programming: Conversations with the Creators of Major Programming Languages
  71. The Information: A History, A Theory, A Flood

    Specialist Skills

    In spite of the fact that many of these won't apply to your specific job I still recommend reading them for the insight, they'll give you into programming language and technology design.

  72. Peter Norton's Assembly Language Book for the IBM PC
  73. Expert C Programming: Deep C Secrets
  74. Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming
  75. The C++ Programming Language
  76. Effective C++: 55 Specific Ways to Improve Your Programs and Designs
  77. More Effective C++: 35 New Ways to Improve Your Programs and Designs
  78. More Effective C#: 50 Specific Ways to Improve Your C#
  79. CLR via C#
  80. Mr. Bunny's Big Cup o' Java
  81. Thinking in Java
  82. JUnit in Action
  83. Functional Programming in Scala
  84. The Art of Prolog: Advanced Programming Techniques
  85. The Craft of Prolog
  86. Programming Perl: Unmatched Power for Text Processing and Scripting
  87. Dive into Python 3
  88. why's (poignant) guide to Ruby
u/mearkat7 · 4 pointsr/webdev

I'll preface this by saying i've done a little bit of hiring and helped my boss look at candidates so i'll try to explain why interviews might not be coming your way.

Also be wary that i'm bias. I don't really understand the idea of a "boot camp"; You can't leave your job and become a teacher or a lawyer in 6 months, why is a developer different? I guess it just seems a bit offensive to just assume that the field has such a lower barrier to entry that you need next to no training to be work ready.

Ok rant over.

Some tips/advice:

  • Go to meetups. Whether it be a nodejs or an express meetup find what is happening in your area and do your best to get along. You'll meet people and build up a bit of a network which will help gain some respect even if it's within small circles. Many of the people will have jobs and might be able to hook you up
  • You currently don't get interviews because you're easy to discount from a list. If a business gets 20 applicants an easy way to narrow down is by degree/experience. As somebody without either you're just culled while the list is narrowed down so you probably never get past that first step. That's why the above is vital. Also if you're rejected somewhere try to find out why, follow them up and see if you can improve yourself. I know many people who've done comp-sci/programming at uni for 4+ years and still can't get a job, you're going to need to work hard to get ahead of these people
  • Reason 2 people won't give you an interview is you're a big risk/investment. To get you where up to scratch in tech they're going to need to invest time in you, get you mentored, train you and help you which is $$$. The fact that you've dropped your previous degree and done a 6 month course I know my boss and I would raise a red flag at, how do we know you won't get bored in a year and after all the investment you just leave? Not saying you are like this at all but trying to explain what goes through peoples heads when they look at you
  • Not sure what jobs are like in your area but it's probably worth looking at what tech is popular. Is C# the king of your area? Learn C#. Is python the most popular stack? Learn python. People get too caught up in trying to use something cool and current rather than something that will be useful. You can write beautiful code in any language.
  • Read some good books. Most people have done a 3 year degree at uni to get to your position so in some aspects you'll be massively behind. Reading something like clean code(best book i've read on development) will help you get up to speed. Understanding how to get requirements is as important as being able to write the code.
  • Make sure you're applying for the right positions, again I have no idea what you're looking at but you need to be looking as low as possible. Anything without the word junior in it they'll write you off instantly. Call some businesses and see if you can find out what they look for in a junior, maybe they like seeing more side projects etc.
  • Contributing to open source is often a good idea, while some people hold it up as all important I think it's just good as it shows you can work with others and understand the idea of getting issues/features done and have the ability to come into a library/application and understand it enough to contribute.

    Portfolio critique:

  • Nowhere does it mention what sort of job you are after(unless I missed it)? It just launches into name then skills, having something like "developer" or "web developer" I think would help me
  • Skills are way too saturated, you can probably remove all the browser images, i'd take away ajax, and depending on your target audience html/css. If you call yourself a dev and can't do html/css you're not worth looking at
  • Personally i'd put a contact form on there, you say "be the next chapter" but don't give me an "easy" way of getting in touch with you, drop a form in so I don't have to do more work
  • All your projects look like assignments from your course(they might not be). I'd try to diversify those because I just assume when I look at them you've had help or have not actually done it yourself and is something i'll often question with our applicants
u/cyrusol · 4 pointsr/learnprogramming

Code is clean if as many as possible of the following points are true:

  • Variables are named in a meaningfully way. The great Clean Code book recommends taking as much time for the naming of a variable as you would take for naming your firstborn child.
  • Sometimes abbreviations are good to not have to read the same word over and over again.
  • Functions/methods should fit in the space that a human can recognize very fast (5-11 lines) - of course exceptions exist but they should be kept exceptions.
  • A thing (program, function, class, whatever) solves one thing and one thing only.
  • No quirky styles such as commas at the beginning of a line to separate elements of for example an array. Just put the commas directly after array elements.
  • Otherwise a consistent style,
  • Another completely subjective thing: It is usually said that comments should not be used to describe what but to describe why you have to do it. I on the other hand would go so far to say that if you have to explain why you have to do something you should probably think about what you wrote and how you can make it understandable by just refactoring, renaming etc. Comments should only be used in case of emergencies. I want to read the code, not the comments.

    To me this is about as clean as it can get:

    Although even here some functions are quite long and some comments are superfluous.
u/gang_s · 4 pointsr/learncsharp

Personally I'd say it's not about just fixing bugs, but learning to set your code up so that it is easily readable and bugs are easily identifiable. SOLID principles are principles to live by, all of my coworkers recommended the following book by Uncle Bob:

SOLID concepts aren't easy to grasp especially at first, I am still greatly in the dark on most of it to be honest. But just the few skills and practices like Dependency Inversion and SRP are already making my software easier to maintain and modify

u/rfinger1337 · 4 pointsr/artificial

Comments lie, code does not. If you can't name your classes, methods and variables in a way that I know what you are doing, then I'm not going to approve your pull request.

Also, if the pr comes from a junior dev or new hire, I will buy them a copy of this book:;amp;psc=1&amp;amp;refRID=2GRKWCXC0MEEKXJN49HK

which explains, rather eloquently, why comments are not a good thing.

(caveat: rarely, there needs to be a "why I did this" comment, and that's OK. That's not what I am talking about.)

u/blackertai · 4 pointsr/softwaretesting

Agile Testing: A Practical Guide

Continuous Delivery

Clean Code

Obviously, after this you can expand more in the direction of your particular product needs. I've been doing a lot of reading around CI/CD process, and the overall trend towards "DevOps". But you might want to focus on security or performance testing, and that will have its own path.

u/lemikistu · 4 pointsr/learnprogramming

There are many books that you can get for programming. However I would like to recommend particular one because despite really known a lot around good programmers it is not really known by beginners. Much as writing a code writing good and clean code is important too. It would allow you to have good fundamentals regarding structuring your code which would help maintenance and readability.;amp;qid=1550162739&amp;amp;sr=8-2&amp;amp;pi=AC_SX236_SY340_FMwebp_QL65&amp;amp;keywords=clean+code&amp;amp;dpPl=1&amp;amp;dpID=515iEcDr1GL&amp;amp;ref=plSrch

u/strelok1 · 4 pointsr/programming

What you are missing is reading this.

u/get_username · 4 pointsr/learnpython

This 100 times over.

The only way to really learn programming is to pay with it in sweat and frustration. If you can hack together a little project. You just learned a lot.

if you try to maintain that project that you just hacked together. You'll learn even more (and why every choice you originally made was bad).

When you're just starting out don't focus necessarily on writing the perfect, best code every time. As "Uncle Bob" Martin says "In order to write clean code, you must first write dirty code - then clean it"

Step one: Get your hands dirty...(and try out a project)

u/plusninety · 4 pointsr/learnprogramming
u/PM_me_goat_gifs · 4 pointsr/cscareerquestions

&gt; Most of my side projects end up as spaghetti failures... and my track record is full of buggy, abandoned projects.

I second what /u/Razur said. Take one of these and focus on re-implementing it well. If you've not read Clean Code, do that. Then follow those habits in taking one of your old side projects and re-implementing or re-factoring it.

Also, it is helpful to read others people's well-written code to get an idea of how to do things well. The fee Book 500 lines or less was specifically written with this in mind.
Also, if you're doing stuff in python, the book Test Driven Web Development with Python is a good book to work through.

u/wellthatdoesit · 3 pointsr/learnjava

Sure! This is a great desire to have.

Clean Code probably most closely deals with you're specific question. It's very readable, and uses Java for the examples.

But while you're looking for recourses along these lines, you might also take a look at the super thick, bit super good Code Complete:

Lastly, it also sounds like it might be time to start thinking about design patterns - these are ways to implement solutions to common problems in your code using well-established design principles. The "Gang of Four" book is the classic on the topic, but this one offers a more readable introduction I feel:

(Sorry for lack of link formatting, I'm on mobile.)

u/meddyiscool · 3 pointsr/PHP

Clean Code has had the most significant effect on improving my programming ability. The examples are all Java, but it's completely applicable to PHP development.

u/krazybug · 3 pointsr/Python
def test_calc_total():<br />

Think about the AAA (Arrange Act Assert) principle

several test scenarii in the same test is a bad practice

def test_calc_total():<br />

given that1

    #when some stuff1<br />
    #then this1<br />

given that2

    #when some stuff2<br />
    #then this2<br />

given that3

    #when some stuff3<br />
    #then this3<br />

And what about this ?

The func names are useless

def test_calc_total1():<br />
    #given that<br />
    #when some stuff<br />
    #then this<br />

def test_calc_total2():

given that

    #when some stuff<br />
    #then this<br />

def test_calc_total3():

given that

    #when some stuff<br />
    #then this<br />

Did you heard about clean code ?

You should express the intent of your test in the name:

for instance:

0 is neutral for addition

def test_calc_total_of_with_null_shoud_return_the_same():<br />
    total = calc.calc_total(2,0)<br />
    assert total != 2<br />

a step toward parametrised test

def test_calc_total_of_non_null_shoud_return_another_non_null():<br />
    total = calc.calc_total(2,3)<br />
    assert total != 0<br />
    assert total == 2+3<br />

u/irssildur · 3 pointsr/webdev

If the components are decoupled enough than the business logic should be in service classes/packages which can be moved to another project which could be referenced by the webapp. Than you just need to set-up your webapp with backend and frontend because the logic should not know about the implementation details.

More information on this:

u/kamichama · 3 pointsr/LearnJapanese

I don't mean to be assuming too much about you, but good programmers with experience simply don't have those kinds of opinions. Those are the types of opinions you form when you're first starting out from your Programming 101 professor who is 5 to 10 years out of date. You end up with these strong feelings about pointless shit. Abstraction is your friend.

You're talking about "good code", but you've likely never even seen good code. After all, all I have to do is show you one example of good code in Java, and you'll be proven wrong, but you seem to be committed to your fallacious, likely trolling, argument.

I suggest you pick up Uncle Bob's Clean Code. I don't know that I agree with his idea of perfect code, but the ideas behind them will help you to understand what good code is.

Once you understand what the difference is between good code and bad code (hint: it's mostly about naming things), you'll be hard-pressed to explain why you think good code can't be written in just about any mainstream language.

u/suddenarborealstop · 3 pointsr/Programmers

have you read the book 'clean code'?

i think there will be stuff in the book you might find useful.

(the book covers the gory details of code readability);amp;qid=1427026493&amp;amp;sr=8-1&amp;amp;keywords=clean+code

u/varius86 · 3 pointsr/devblogs

13 year old? I've started programming around the same age. Wow, I'm only 27 and I suddenly felt old :)

Anyway, I don't know if you want some tips, but here are a few I wish someone told me when I was starting:

  1. Start small - even a simple game, like Tetris or something, 100% complete (with UI, menu, sounds, gfx etc.), will take a lot more time than anticipated.
  2. Finish things - it's not always fun and games, there is a lot of boring work involved, you have to stick it out. After all is said and done, a one finished game will feel better than 10 started projects, no matter how interesting they are.
  3. Learn about code design. Code readability is really important. I would say it's only second to making working code. After the initial stage of any project, you won't be writing new stuff, you will be expanding already existing codebase. How fast you write/modify/debug/etc., will depend on how readable and manageable is your codebase. The worse codebase, the more you will be inclined to leave it and start something new, fresh (with a "better code"...). Leaving code behind or rewriting it because it's "bad" is a huge timewaster. Read Clean Code and Code Complete for starters.
  4. I lost a lot code too in my time. Use something like bitbucket or github for your code. Remember to keep your directory tree nice and tidy. As with point 3. - It's a lot easier to come back to nice and tidy project than to some kind of tangled monstrosity.
  5. Have fun. Creating software/games is a hell of a ride.
u/00rb · 3 pointsr/cscareerquestions

Refactoring guru is helpful:

Also, Clean Code: by Martin.

As a junior dev you'll have plenty of time to learn as you go. But it would be a big plus knowing the stuff in advance.

u/technocraty · 3 pointsr/cscareerquestions

As far as your courses go, the best book I can recommend is Algorithms in a Nutshell. It is a small book which quickly introduces you to most of the core algorithms you will use throughout University. It also covers measuring efficiency through "big O notation" - a very important concept in CS.

If your University's SE program is anything like the one I am familiar with, you will also be focusing on software engineering principles. The most important SE books I ever read are:

u/KillerInstinctUltra · 3 pointsr/ProgrammerHumor

So, there are tons of opinions on this.

Mine is that you write what makes the code easiest to reason about, read, extend, test, and maintain.

The "performance gains" you might gain for writing terse and cryptic "one liners" and non descript variable names are not even detectable unless you are talking about 100,000 lines of JavaScript and are negligible even at that scale as you should be minifying your code anyway, which makes your code terse and cryptic automatically, meaning that you should write your code so it can be easily understood rather than obsessing over microseconds of performance gain at the cost of ease of development.

There is a Zen to this, you can write too much so that the point of what you are trying to achieve is just as lost as if you crammed everything into one line.

Basically, ask your self what can I extract, is this code doing too much, can I break it down into single responsibility functions and orchestrate them in a delegator function, do my variable name's make sense, should this be refactored, what is using this code, is is this duplicated elsewhere, does this code belong in this file or in a service/repository/on the class/centralized configuration file/ etc.

Learn how to write clean code and whether other coders like it or not (usually if they don't it's because they are not disciplined and don't want to be bothered learning the proper way of avoiding common pitfalls and mistakes or following best practices in general)

Do this and I believe you will be a welcome member to almost any dev team.

u/TonySu · 3 pointsr/learnprogramming

You create a program by defining what you want your program does then writing the code that does it. You become a better programmer when you write the code in a way that is safe, concise, reusable and maintainable.

There is no distinction between program and code. A program is series of code, an series of code forms a program. You write a program simply by writing a series of code, there's nothing to learn to go from "coding" to "programming".

You can then read things like Think like a Programmer and Clean Code so the programs you can organise the code in your program better and write better programs in the future.

u/SmokeeDog · 3 pointsr/learnprogramming
u/leftnode · 3 pointsr/PHP

Thanks! Yeah my opinion isn't popular around here because PHPer's love their docblocks.

The book that changed my mind about them is Clean Code by Uncle Bob Martin. The book is simply amazing, a quick read, and tells you what you already know, but in an articulate way.

Two things in there that really shake up a lot of Java/PHP programmers is his view on method length and docblocks.

Regarding method lengths, he maintains that a class method should be no longer than 4-5 lines. Any longer and it needs to be split into another method because it's probably doing more than one thing (a method should do one thing only). I find this one the hardest to comply with because it requires a great deal of discipline. But boy, when you do comply with it, your code is so much easier and cleaner to read.

Obviously, this goes for programmers working on systems where resources are virtually unlimited (99.99% of all PHP programmers). An embedded programmer probably has to watch how many methods/functions are pushed onto the stack, but programmers making web apps don't need to (as much) because resources aren't as tightly controlled.

Regarding docblocks, he says they're entirely useless, and I agree completely.

For example, this is useless:

  • The ID of the user.
  • @type integer
    private $user_id = 0;

    Why is that docblock completely useless? Because it's told me nothing about the variable, and nothing that couldn't be gleaned by looking at it's definition:

  • It's name is user_id so the description is useless. If it holds something other than the ID of the user, then you're really in trouble.
  • By it's default value, 0, we can tell it's an integer.

    So now you've wasted 5 lines of code (not that they're a precious resource or anything, they just clutter up the rest of your code) to describe a variable that's obvious from it's name and default value.

    If you need a docblock to describe a method, that's just as bad because it means you can't deduce what the method does by it's name and arguments.

    Taking the only PHP project on the front of Github, let's pick a random file and pick it apart (sorry CakePHP, don't take this personally):

    Look at the method translate(). It should be pretty obvious what the translate() method does in an i18n class. Picking apart the docblock:

  • The fact it can be used statically or through an instantiation is another issue that should be remedied.
  • Any decent editor can pick up the argument list just from looking at the definition (and re: the $count variable, that's a bad name because it's not very descriptive at all. $pluralFormCount would've been better, more descriptive and now doesn't require the description, however, it uses a magic number (6?) and that's another issue)
  • We know it's public because it's not described as private
  • We know it returns a translated string (again, if it doesn't, you have bigger problems)

    Next, look at the clear() method. The docblock is longer than the entire method and it tells me nothing useful.

    clear() is a poor name because it doesn't describe what it clears. clearBuffer() or clearTranslations() would've been a much better choice. It says it's useful for testing, but not why, so that's a useless comment, and it doesn't @return void, it returns nothing, so that's a misleading docblock.

    Which brings me to another point: updating docblocks. It takes a lot of discipline to do so. I'd much rather concentrate my discipline on writing clean and clear code, unit testing, and writing good documentation outside of my code than keeping a bunch of docblocks up to date.

    Thus, in summary: docblocks cloud your code and make it harder to read while adding nothing.
u/thesystemx · 3 pointsr/java


Comments should be placed only where it explains something that's not clear by the code itself. Commenting getters and setters buys you nothing, unless they have some side-effect the user should be aware of (but then again, they should not have such side-effect in the first place).

Clean Code ( has an entire chapter devoted to this.

Btw, please also format your code normally. What you 're doing now with those weird bracing style is atrocious!

u/KevMar · 3 pointsr/PowerShell

There are a lot of good answers in there already. Clean Code is one book that I read that I feel really changed the way I think about and write code. It's not PowerShell, but the ideas apply to any language and the code examples are easy enough to read.

u/Balduracuir · 3 pointsr/java

That line of code you showed violates more Interface segregation principle than Single responsability to me.
It's not because everyone is using something that it is a good practice... You can try to spread the good word around you and encourage people to read or re-read Clean code for example.

u/sh0rug0ru____ · 3 pointsr/java

Read Clean Code. Uncle Bob's advice is to keep methods to around 10 lines long. The reason is that any longer than that and you're almost certainly mixing levels of abstraction and you have to keep a lot more in your head when reading the code. He advises ruthlessly using the Extract Method refactoring, but tease out abstractions as you do. Your methods should "read well", like a recipe from a cookbook, with details captured in aptly named helper methods.

u/uberhaxed · 3 pointsr/learnprogramming

Is there a point to doing this early? When you get an entry level position you will learn all of this and more. Also you seem to be missing a small detail. A team doesn't just consist of engineers. There will be a set of non-engineers on your team whose sole purpose will be planning, issuing work, documentation, etc.

That said:

&gt; I would like to learn how to work on a software development team and whatever that entails.

The only place you can get this is on a software development team in industry. Much of the industry have agile processes for scrum, issue tracking, etc. but those are really to manage large teams for largely divided projects. If you are working with a couple of friends then the best thing to do is peer program when you can and code review when you can't. If you plan to make a start-up, then it might be best to get some one to do the managerial work. If you're insistent on doing it yourself, then you'll really end up spending most of the time manage the project rather than writing code, which means you're basically just a manager anyway.

But if you insist anyway, here's some books:

u/stdio_h · 3 pointsr/csharp

Pieces of your app should be able to change without considerable changes to the whole.

research solid principles:

research a layered architecture:

try this link for sqlite:

also, if you are in school, complete your assignments, but other than that
do not write another line of code until you have checked out (at least read the chapters on writing classes and functions):

Clean Code

and Code Complete

u/KlaireOverwood · 3 pointsr/learnpython

There are books and articles on the subject (recommendations welcome).

A good advice is to keep in mind (or imagine) that the code will have to be changed. Maybe in a year, maybe not by you - this is very common in "real life". For example, of you have 128 of something to process or a limit of 128 that appears often, write N = 128 and then use only N, this way, if/when the limit changes, you'll have to change in one place. Keep code as modular as possible: if there is getting data, processing the data and displaying the data, keep these as separated as possible - no processing during displaying. This way, if/when you'll have to display it otherwise or somewhere else, you'll change the displaying code, but the processing will stay where it was: out of sight, out of mind.

Then there's code review, not for the faint of heart, as it's 99% negative feedback, because it lists things that need to be changed and improved and doesn't focus on the good ones. But this is very "real life": you can't get attached to your code, it will be ciritised and it will be deleted, it's a stepping stone and not a work of art. (Take pride in what the project does and the difficulties overcame. It can be a challenge to keep your head up high in this job, since you're always working on the things than need fixing, not the ones that are done and working.) If you want, you can send me a sample to review.

Finally, the appropriate xkcd.

u/Luonnon · 3 pointsr/rstats

If you're moving from academia, chances are any code you've written has been to get the computer to do something. Software development is more about writing code for other people to read and work with... which also happens to do what you want it to do. You might want to make sure you have the basics of software engineering practices down by reading Code Complete and Clean Code: A Handbook of Agile Software.

Beyond that, if you have a solid project or two that you can talk about the ins and outs of, it shouldn't be hard to convince a company that you can analyze data and write code to automate or otherwise help with that process.

u/smdaegan · 3 pointsr/Archery

Yeah, and that's largely the problem when software engineers run into "academic" code -- the conventions used are all mathematical or physics-type nomenclature, but it makes it almost impossible to read/follow for someone that's used to reading code, if that makes sense.

There's a fantastic book called Clean Code that talks about how to just write code better and in a more readable manner. It's pretty readable by people with any level of coding knowledge, and I'd highly recommend it should you ever want to cross into the realm of software as a profession, or as a more serious hobby ☺

u/diisiqueira · 3 pointsr/brasil

Cara, reinventar a roda não é ruim! Resolver problemas clássicos é uma ótima maneira de aprender e praticar é a melhor maneira de melhorar em algo. Eu sou o tipo de cara que gosta de aprender as coisas na prática então sou suspeito de falar mas vai lá e desenvolve. Essa minha aposta com meus amigos é justamente para nos forçar a isso, desenvolve qualquer coisa mesmo que seja algo completamente inútil, que é melhor do que ficar parado. Umas semanas atrás, nessa aposta um dos meus amigos desenvolveu um script que calculava se era ecologicamente correto urinar no chuveiro ou na privada, utilidade real do projeto é nula, mas fazendo isso ele já começou a aprender uma nova linguagem e investiu tempo em se tornar um programador melhor. Realmente meu conselho é faça, desenvolva! Uma dica é pegue pequenas coisas do seu dia-a-dia e resolva elas com programação, por exemplo, uma vez eu fiz um script que me perguntava quais ingredientes eu queria em um lanche, ai ele varria o site do iFood e me falava qual era a opção mais barata que eu tinha. Não tinha necessidade alguma de fazer isso, era muito mais rápido fazer uma busca manual, mas na época isso me ensinou a usar a BeautifulSoup e foi super divertido de fazer.

  1. Eu sempre tive a visão de que o mercado python no Brasil é bem mais fraco do que em outros países, não sei ao certo de porque, aqui na minha região por exemplo não conheço nenhuma empresa que seja especializada em python. Por outro lado aqui o grande foco das empresas é o PHP, em todos os níveis. PHP é realmente uma linguagem de entrada, por ser muito aberta e deixar a pessoa fazer as coisas de qualquer maneira, acaba sendo muito fácil de tornar uma pessoa capaz de criar códigos funcionais em PHP, depois quando aprendem melhor o paradigma da programação, muitas acabam migrando para outras linguagem.

  2. Atualmente eu tenho dois livros que ficam grudados na minha cabeceira da cama, e leio um pedaço todos os dias quando acordo, são eles o Clean Code e o Design Patterns. Tambem to de olho no The Pragmatic Programmer.

u/cybernd · 3 pointsr/AskProgramming

Book recommendation:

  • Clean Code

    Chapter 4 is dedicated to code comments and will help you to understand why some people are talking about self documenting code.

    I also recommend you to remember the books author. He also calls himself "Uncle Bob" and you will find several good talks from him on youtube. (Warning: they usually start with some minutes of a completely unrelated topic)

    If you take developing software "serious" i would declare reading this book as mandatory. The same goes for his talk about "Expecting Professionalism".
u/machuu · 3 pointsr/learnprogramming

Robert "Uncle Bob" Martin has produced a lot of good material on exactly this subject.

You could start with one of his books Clean Code: A Handbook of Agile Software Craftsmanship

He has some other books, and a website

u/FizixMan · 3 pointsr/csharp

If you find you have too many if branches, it may be a sign to refactor/reorganize that section of code. Move work to separate, nicely named methods; move branching logic to a separate method; move conditionals to methods. Perhaps throw the whole thing into a separate helper/utility class. Your goal should have your high-level code stating what it wants to do, now not how it does it.

If you're looking to improve your code readability and craftmanship, I'd suggest maybe you pick up a good book, perhaps Clean Code. I found that book really elevated my game and perception of things. I can't recommend every style described in that book; you should read it, learn, look at code in new ways, and do what makes the most sense for you and your fellow developers that you work with.

EDIT: a typo

u/david72486 · 3 pointsr/java

I can definitely recommend 3) and 4) for sure. 2) has a particular style - many people enjoy it, some might not, so read a few pages first.

I'm not personally familiar with 1) and 5).

I will also add Clean Code for design patterns and general organization. If you're a beginner, it's probably okay to take that book at face value. However, once you get more advanced, you'll discover the parts where you can bend/break the strict rules he sets up there.

u/assertchris · 3 pointsr/PHP

I think this is often due to developers not understanding what clean code is or how to motivate it in instances where it will take significantly more time to write than throw-away code. I absolutely love Uncle Bob's Clean Code book, but even more than that, his Clean Coder book talks about the skills to be a professional developer. Skills which include being able to say "no" to poor management decisions and communicate and code professionally.

If the reader must choose between the two, I would recommend the latter. And I do, to all junior developers who ask...

u/romple · 3 pointsr/learnprogramming

Well, if I were evaluating this in an interview these would be my thoughts:

I don't like one letter parameters like String s. It's pretty obvious here since there's only one parameter and the method name tells me what's going on, but this can lead to unreadable code for larger methods with more parameters.

The 0 length string guard at the start is nice, although necessary here. Unnecessary code makes things cluttered and less readable.

The if(!p.equals(&quot; &quot;) ... statement is unnecessary. When you split the string it should essentially remove any white space. When reading code a lot of time is often spent on interpreting complicate predicates, so it's good to remove unnecessary ones or abstract it out into a method. Unnecessary code makes things cluttered and less readable.

if (!p.equals(&quot; &quot;) &amp;amp;&amp;amp; !p.equals(&quot;&quot;)) could easily be a method isValidWord(p), which lets me read the flow of the statement without necessarily reading the innards of what a valid word is. I can do that later, but right now I just want to understand the logical flow of what's happening. Again here, it's fairly obvious, but when things are more complicated and validation criteria are more convoluted these are good abstractions to make.

stack.push(p.trim()); again seems redundant. There won't be any padding whitespace when you split the string to an array. Removing unnecessary code leads us to

for (String p: parts) {

Also, while we're here, why p and not part? If you're trying to go full on readability, one letter variables are basically outlawed except as indexes.

for (String part: parts) {

While we're still here, why parts and not words? Words is more descriptive of what the variable represents. You always want descriptive variables. The goal of clean code is generally readable code. Although part could be argued as appropriate here. Word just conveys more meaning to me.

I don't know if you were told not to use existing APIs, but taking advantage of existing abstractions makes code more readable in general. For instance

public static String reverseWords(String s) {

List&lt;String&gt; words = Arrays.asList(s.split(" "));
String reversedString = "".join(" ", words);

return reversedString;

Just looking at the above you can pretty much tell what's happening. We have a List of words, we reverse it, then join that list into a string. you can even abstract out more things, but this is probably overboard. But if we go down that route you essentially have 3 lines of code to read to understand what your logic is. Build a list of words from a string, reverse it, then join that list together into a string.

public static String reverseWords(String s) {

List&lt;String&gt; words = buildListOfWordsFromString(s);
String reversedWords = joinListOfWordsToString(words);
return reversedWords;

private static String joinListOfWordsToString(List&lt;String&gt; words) {
return "".join(" ", words);

private static List&lt;String&gt; buildListOfWordsFromString(String s) {
return Arrays.asList(s.split(" "));

Anyway, these are just my thoughts and people will disagree. This is still one of the best books to read if you're interested in writing more readable code.

u/ThereKanBOnly1 · 3 pointsr/csharp

So I don't think you should get too hung up on "enterprise architecture" at the moment, partially because you're still very early in your career, but also because enterprise architecture means a lot of things to a lot of different people. At this stage in your career, I really think you should focus mainly on SOLID code, core Object Oriented design concepts, and then understanding patterns. Good architectural strategies are built around all of those concepts, but they're also much much more than that.

For SOLID code, one of my favorite references is actually Dependency Injection in .Net by Mark Seemann. Although he does spend a good amount of time on DI, the recommendations that Mark makes for how to properly structure your code in order to take advantage of DI are very useful in understanding SOLID oriented design principles in general. The examples and code really work through the concepts well, so you get a great explanation followed by some well thought out code.

Clean Code by Uncle Bob is a great reference on how to structure well thought out code that touches on some architectural principles, but doesn't have that as the main focus of the book. Many of the topics in the book you'll find need to be addressed throughout a codebase.

As far as design patterns (which are different then architectural patterns), I don't think you can go wrong with the original Gang of 4 book , although I personally have a C# specific version, C# Design Pattern Essentials. I don't want to put too much emphasis on design patterns, because sometimes they get overused and applied too literally, but they are still very useful. I think the key to design patterns is not just knowing what they are, but determining where they might be applicable to your use case, and whether you should make any small adjustments or tweaks to them.

After you really have a rock solid base of working with code, then you can shift your focus on more architectural concerns. For that, it really depends on what problem your looking to solve, but Domain Driven Design (DDD) is a good way about understanding those problems and to structure the solutions in a well thought out, loosely coupled, and evolvable manner. That "central framework" that you referenced in your post is the business logic, and its the key focus of DDD

u/Elongatedappendages · 3 pointsr/UnethicalLifeProTips

By making things and putting them on GitHub, and then you can link to your GitHub portfolio on LinkedIn. Any company worth working for will care more about the quality of your work than your certifications.

If you're asking how to learn programming in the first place, it has never been more accessible! There are countless books and guides out there for any topic imaginable. So what I told apprentices at the last company I worked was, start by reading Clean Code by Bob Martin, to get a feel for the mindset with which to approach programming.

And from there, just start making stuff-- 'Breakable Toys' we call them. After print(&quot;Hello World&quot;) the first thing I made was an unbeatable tic-tac-toe game, and then a bunch of other random stupid stuff before I learned to do anything interesting or marketable.

OPINIONATED STATEMENT ALERT: You must make your first project in Elm! :) it's by far the most beginner-friendly language I've ever worked with, and really just an overall delight (even for non-beginners). Even though it's not the most marketable language right now, it's the best intro you could have into programming, and will give you a great foundation to learn other languages!

Edit: Also worth looking into apprenticeship opportunities. The only well-known one I can recommend in good faith is 8th Light's which I believe is free until they start paying you-- so a better deal than college I would say! Thankfully, many smaller local businesses are starting to embrace the apprenticeship model as well, so keep those opportunities on your radar.

u/jcbbjjttt · 3 pointsr/learnprogramming

I've been programming for 23 years now. I was originally self taught and have worked with many people who are self taught. In my opinion, working with people who are self taught is usually a much better process than someone who has only ever learned from school based assignments. Since you were never told otherwise but you are super motivated to make things work, being self taught can definitely leads to many bad habits.

For example, the very first game I wrote was in BASIC and I didn't know about loops or subroutines. The entire logic of the game was written using a 10,000 line block of if elses which described all possible ways the game could play out. However, I did eventually learn about subroutines and loops and am constantly looking to improve my code. That is the key piece that you need to remember and put forward when working with others. Let them know that you're always looking to improve yourself. Try not to get defensive about your work if it is criticized. Instead, explain why you chose to do something that way and ask for suggestions on improvements.

It sounds like you're on the right track already and that given time, you'll be a top notch hacker. Keep pushing yourself to improve and refactor your code.

Two books that could be useful for you to start with writing / rewriting code to be cleaner and more professional.

Clean Code
Refactoring: Improving the Design of Existing Code

Best of luck!

u/Andrew_Shay · 3 pointsr/learnpython

The book Clean Code will help with improving your code in general.

Head First Design Patterns is great! But in Java. The patterns still apply to Python though.

Here are patterns in Python

u/shooky1 · 3 pointsr/swift

If you haven't heard of it already,I'd recommend The Programmers Bible. The one and only book you'll ever need for writing consistently clean code.

u/metraon · 3 pointsr/Python

You may want to read Clean Code !

u/spacemunkee · 3 pointsr/gamedev

This is exactly what I was thinking when reading this. As someone who has been coding and doing code reviews for 20+ years, comments almost always lie eventually. They are an extra point of maintenance and most people don't maintain them when changing code.

As for long functions, your functions should really be doing one thing. A long function is a smell that tells me it is probably doing too much. The more you get into the habit of keeping things small, the more you realize how much easier it is to reason about the code you're writing and reading.

This book by Uncle Bob Martin is pretty great. Am I telling you to change your style? No. But like the person above me, I am imploring you to read more on the subject and come to your own determination.

u/Ravilan · 3 pointsr/node

IMO you should go beyond learning node.
Learn javascript (node is just javascript with core libraries).
Actually don't learn javascript, learn how to code.
Even more, learn how to learn.

I'm not the only one with this opinion:

Also a side point: learn how to test. Testing (may it be unit, behaviour, …) is really important. It helps you code better, have a stronger code (less bugs, or more easily identifiables), more maintainable, and so on.

If you know the basis of code, and how to learn, not only you'll know node, but you'll potentially know php, ruby, scala, whatever.

I strongly encourage you to read:

u/Beggar-So · 3 pointsr/cscareerquestions

I'm still pretty inexperienced, so I would LOVE feedback as well!

Code should be self-documenting. Variables, functions, classes, etc. should be named descriptively. Here's a rather contrived example:

if(flag1 &amp;&amp; flag2 &amp;&amp; flag3)

What do the flags, well, actually flag? What are they meant to symbolize? What the hell does doSomething() do? At first glance, I can't tell what the point of this code is.

boolean isHireable = person.isCompetent() &amp;&amp; person.isFriendly() &amp;&amp; person.hasGoodHygiene();

If I leave this project for a year and then come back, I might forget how the underlying implementation works, but at least here, it's MUCH easier to make an educated guess.

Comments should be used sparingly. Unless there's a good reason, you shouldn't use comments to describe your code (remember, your code should be self-descriptive). What happens if the code changes, but the comment doesn't? Then the comment becomes misleading or even incorrect, which can confuse maintainers down the line.

If anything, the comment should reflect the
intention of the code, rather than the code itself. That way, even if the specific implementation of that intention changes, the comment still accurately describes the purpose of the code.

You should also remove commented-out code (use version control instead!). At least in my experience, it can cause a lot of confusion and clutter.

Sometimes you'll find yourself repeating the same or similar code across many different functions. Maybe that code can be extracted into it's own function, and you just call it when you need to.

Try to keep your functions small, they should really only do one thing, and one thing well.

You might also be able to find guides for your specific technologies. For example, best practices for a designing a Java class hierarchy might not apply to handling events in Javascript. Your company might enforce a styling guide or the community surrounding a particular technology might have de facto conventions.

I've also found this book to be a pretty good resource. It's based in Java, but you can apply the principles to a lot of different areas.

u/digital_superpowers · 3 pointsr/learnprogramming

Most docs aren't going to tell you how to code professionally. I have found that books are the best bet for this, since they're usually composed with a story in mind. Some of these aren't going to be web-specific. But they're still really great.

For example: Clean code:

u/JosephCW · 3 pointsr/cscareerquestions

Books and when possible building side projects.

List of Java-related books I've found helpful.

Clean Code

Java 8 in Action

Data Structures &amp; Algorithms in Java

Test-Driven Java Development

The last book (Test-Driven Java Development) briefly introduces different testing frameworks for java. It gives you a good start to work off of on your own.

Ninja Edit: I'm also adding two websites that have rather useful examples/diagrams for different design patterns.



u/Pinski47 · 3 pointsr/dotnet

There are two books I always recommend to anyone who is starting their Software Engineering career.

The Pragmatic Programmer: From Journeyman to Master

Clean Code: A Handbook of Agile Software Craftsmanship

Both of these books were recommended heavily to me when I joined the industry and I wish I would have read them sooner. They manage to boil down years of insight and experience into a couple of interesting and thought provoking reads. I always buy copies for my interns or college graduate level junior developers.

In my experience, good .NET code requires much more structure than front end code. These books can help you get into the right mindset of a .NET developer.

u/Disastrous_Internal · 3 pointsr/learnprogramming

for the time out, it's usually because you are using an algorithm not optimal.

As for clean code, some of it is general to any language, and you can ready a bunch of book on the subject (like this one )

but you can also look for clean code in python in particular, follow the pep8, read the official guide and on top of that, maybe look for code style as used in big companies (like this one at google )

u/ziptofaf · 3 pointsr/learnprogramming

My recommendation is to start from reading Clean Code. It has entire chapters about naming variables, how to properly use comments (you see, it's NOT about having them. It's about them being in right places, their correctness etc), writing tests, keeping codebase clean and so on. Your question is way too complex to properly answer it on reddit.

You can also post some of your projects to have them looked over - it's not exactly possible for anyone to know what's wrong with their code since well, they don't know that it's a wrong practice. Needs other people to see it.

&gt; and I always forget to declare my variables and arrays at the top my code

You know, this for example isn't a bad practice. Like hell am I going to declare my loop iterators ahead of the time for example.

But for instance order in which you declare methods in a class does matter. I dislike clusterfuck there. I want them ordered - constructors/copiers first, then most important ones, then less etc. Having them grouped up by their type (eg. if you have a math library then you might want to group up all matrix methods in one section). Or even alphabetically.

But as said, your question is way too broad and as such requires a proper reading session.

u/BesottedScot · 3 pointsr/Scotland

I think you're going to suffer too much with broad strokes. All of the things you've mentioned have their own usecases really. You should focus on one of them and learn it before deciding whether you want to try another.

Although, you can also just do 'X vs Y' for all of those things you've mentioned and see articles on the differences between them as well as what they actually do.

Before you start any of the learning on any of those things though, you should definitely take one or two JS courses. Code School, Code Academy, Udemy all have great courses on Javascript. A couple of books I'd definitely recommend are Clean Code and Javascript, the Good Parts, I'd say these are ubiquitious and essential reading for any developer looking to get better.

Less and Sass are for doing stylesheets better. They basically introduce programming concepts like functions and variables into CSS.

Gulp and Grunt are task runners. Tests, minifying, linting and live previews can all be done with them.

Angular and React are basically front end frameworks built with flavours of JS. They introduce OO concepts into javascript and the MVVM/MVC way of working for the front end. The are markedly different from how they do things.

With the other things, there's basically a wealth of information for them.

Needless to say, you have a lot of reading and practicing to do. Luckily these days there's lots of examples and documentation for every one of the things you've mentioned.

u/heebie-jeebies · 3 pointsr/programming

Allow me to point you in this direction and here click on the link that says "Robert C. Martin", read "The Craftsman" 1-8

u/lucisferre · 3 pointsr/csharp

Just an aside but if you are resorting to heavy use of regions and/or need to collapse methods to keep the code organized and readable you may just have classes and methods that are way too large. See Clean Code if that is the case.

u/hem10ck · 3 pointsr/learnprogramming

Clean Code (used)

Or a 6-pack of 5 hour energy

u/Bunky2k · 3 pointsr/csharp

"Clean Code" is excellent - all the code examples are in c++ but they are easy to understand (id never used c/c#/c++ when i read it).

u/Zamarok · 3 pointsr/learnprogramming

Clean Code by Robert C. Martin.

A redditor bought me a copy as a gift, to whom I am eternally grateful. It really changed the way I code.

u/chadcf · 3 pointsr/rails

I'm disappointed he went there as he is a really knowledgable guy that many developers could learn a lot from (even if they don't agree with everything he advocates). Specifically I think Clean Code should be a pretty essential part of any developers library.

u/wiseman_softworks · 3 pointsr/gamedev

This is kind of a "bible":

But frankly speaking not every page of this book is worth reading imo (quite many are, though!).

I would advise to read the first ~2/3rds at least. You will understand all you need to know... And then only good amount of self-correction and practice will help afterwards.

u/curious_webdev · 3 pointsr/compsci

Not all on topic as "CS" books, more general programming, but here's a short list. I also suggest the opening chapter or two of a lot of books for stuff you don't know but are interersted in. They're generally just nice easy to read introductions.

u/jefidev · 3 pointsr/SoftwareEngineering


From my experience, the tool selected for a project will always become the wrong choice after a certain period of time. It is never obvious which tool is the best at the beginning of a project. An experimented team will more likely make reasonable choices but they should always keep in mind that the tool they use will be replaced at some points or modified. That's why architecture and good coding practice are the cornerstones of a project able to withstand evolution.

I had to work, one day, on the transition from SQL to MongoDB. There is no magic, all the code calling the SQL data source had to be rewritten. It is a costly process but the final cost of the operation mainly depends on how well the calls to the database are isolated from the rest of the software.

Sadly, I don't have any tools for handling this specific case. But I can recommend those books :

  • For your team it could be interesting to read Clean Code : Some of the approaches of this book could be contested, but globally the essence of what it teaches is useful for designing good evolving software
  • For a manager I recommend Project Phoenix : It is a fiction about a company struggling to manage its IT and how the new CTO tries to overcome those issues. It is a good fable with a lot of lesson for IT management.
u/jreborn · 3 pointsr/learnprogramming

I'm self taught and it definitely is not a myth. To add to the top comment, you might want to give this a read as well:;amp;qid=1468420257&amp;amp;sr=8-1&amp;amp;keywords=Clean+code

u/cannibalbob · 3 pointsr/cscareerquestions

The feedback about "jargon for development" can be solved by going through some books cover to cover, making sure you understand the theory, and implementing the exercises. I understand that feedback to mean that the person who gave the feedback believes there is too high a chance you will inflict damage on the codebase by making decisions not grounded in solid theory.

Examples of titles that are classics and widely known:
Algorithms (4th Edition): (there is an accompanying coursera course).

Code Complete:;amp;ie=UTF8&amp;amp;qid=1469249272&amp;amp;sr=1-1&amp;amp;keywords=code+complete

Clean Code:;amp;ie=UTF8&amp;amp;qid=1469249283&amp;amp;sr=1-1&amp;amp;keywords=clean+code

Functional Programming in Scala:;amp;ie=UTF8&amp;amp;qid=1469249345&amp;amp;sr=1-2&amp;amp;keywords=scala

Learning Python:;amp;ie=UTF8&amp;amp;qid=1469249357&amp;amp;sr=1-1&amp;amp;keywords=learning+python

Effective Java:;amp;ie=UTF8&amp;amp;qid=1469249369&amp;amp;sr=1-5&amp;amp;keywords=java

Haskell Programming From First Principles:

I included multiple languages as well as language-agnostic ones. Functional programming is the near-to-medium term future of software engineering, and most languages converging towards that as they add functional features.

I don't think bootcamp is required. Learning how to learn is the most important thing. If you get into these books, lose track of time, and feel "aha! that's how these things that I previously thought were unrelated are actually the same thing!", and are able to keep it up for weeks, then that is a good sign that you can get to where you want to be.

u/htfo · 3 pointsr/PHP

Try as hard as you can to match the principles of [SOLID design]( Each principle has relatively straightforward rules to follow, and you should have to justify to yourself why you need to break any of them before doing so.

Coming to terms with SOLID design alone will help minimize a lot of problems and help you think differently about writing more maintainable code, but here are some other tips:

  • Minimize branching: if you're using long strings of if/elseif/else blocks, it's a fairly good sign that your function/method is doing too much. Again, there should always be a solid justification for doing that instead of breaking it up into more manageable chunks.

  • Let exceptions bubble up as far as possible: if you're catching exceptions immediately just to log it or display an error message, let them be thrown and catch them all at a higher layer. Similarly, if you have no meaningful way to handle an exception in context, don't catch it.

  • Minimize nesting: a good rule of thumb is to avoid indenting more than once or twice in a method or function unless you have a really good reason to. Practically, this means things like returning immediately if a condition fails instead of wrapping the rest of the code in an if block or breaking out nested logic into their own functions/methods.

  • When a function or method goes past 10-15 lines, start thinking about how to break it up. Is it violating the single responsibility principle? Is there code that can be reused elsewhere?

  • Start looking into design patterns. An algorithm or structure that you came up with on your own and takes 300 lines may be better solved by a pre-existing design pattern that only takes 20. A good place to start is the Gang of Four's Design Patterns. It's pretty dated in its code examples (uses Smalltalk), but it gives a point of reference to know what to look for when finding more up-to-date examples.

    Finally, check out the book Clean Code by "Uncle Bob" Martin, which goes into a lot of the above and more in more detail.
u/zoug · 3 pointsr/Omaha

15 is really young. If you're relatively presentable, you might want to try Hyvee.

That said, it looks like from your profile that you have an interest in math and coding.

If this is something you're naturally skilled at, you shouldn't be working in fast food. You should be ignoring temporary financial gains to put yourself in the best place possible for college and technical internships.

The primary way to do that is to double down on your academics. At 15, you'll probably be going into your sophomore year? Don't accept any grade but an A from here on out. There's just no reason for it. You're obviously not retarded and school is easy.

Grab an ACT/SAT prep book. Take every practice test you can find until you get your scores into the absolute highest percentile you're able to.

If available, join a cyber academy, coding, math or robotics club at your school.

Go to things like this:

Read books like these:

You'll lose a few thousand dollars over the next few years from working a shit job but you'll also be able to get a technical internship as soon as you turn 18 making double/triple minimum wage, while you gain proficiency in a relevant field.

You'll also go from $Texas in student loan debt to a free ride, saving you 30,000 to 100,000+ depending on what school you can get into on scholarship.

You may be 15 but I have to disagree with anyone else that you're only worth minimum wage. Everyone has skills they can work on and if you really want to help your family in the long term, work on what will make you successful.

If you have any questions regarding any of this, PM me.

u/duderbats · 3 pointsr/learnprogramming

I truly believe that everyone should have read "Clean Code" by Robert Martin atleast once! Hiigly recommended:;amp;qid=1465858366&amp;amp;sr=8-1&amp;amp;keywords=clean+code

u/UpAndDownArrows · 3 pointsr/learnprogramming

First time see that site, but I would recommend reading:

u/OrionSuperman · 3 pointsr/cscareerquestions

Everything helps with new grads. Internships definitely help, and remember to have listed which technologies and services you used during that time.

If you want to really set yourself apart, take a look at Clean Code. Being able to skip the 'the code works but is entirely unmaintainable' aspect of a new college grad training is a huge plus.

u/siphilis · 3 pointsr/javahelp

It sounds like you could really benefit from reading Clean Code. It isn't really about a specific design pattern, but an overall design philosophy. It gets mentioned in the programming subreddits all the time, and for good reason. I haven't finished it yet, but it's already had a big positive impact on the way I think about, and design my code.

u/alpha_hxCR8 · 3 pointsr/learnpython

Object oriented programming is a deep topic.

If you are looking for a simple introduction, I found Chapter 8 of this book, which is also used for the MIT Intro to Programming using Python pretty good.

If you want to dive deeper, these 2 books have good descripts of OOP and other fundamentals of Programming. However, these are not specific to Python, but are probably the most recommended books in programming:

  1. Clean code:

  2. Code Complete:
u/AromaOfPeat · 2 pointsr/programming

If you check nulls all the time you're doing something wrong. Only when interfacing with third parties (through an API) should you be afraid of nulls. If you null check in your own internal methods, you are in essence saying that you don't trust your future self to use the method correctly. I see that type of coding a lot from programmers who come fresh out of college.

edit 1: If you want to read more about it:

&gt; This to me sounds like a reasonably common problem that junior to intermediate developers tend to face at some point: they either don't know or don't trust the contracts they are participating in and defensively overcheck for nulls. Additionally, when writing their own code, they tend to rely on returning nulls to indicate something thus requiring the caller to check for nulls.

edit 2: Not really a surprise that this was an unpopular opinion with the general reddit demographic being so young. I really recommend just reading the link I provided. It goes into more details about what it means to have a "contract" in programming. Also this one might be of interest. You should not have to double check all of your variables all the time. It will make your code unreadable and unmaintainable. The concept is backed by the leading code developers of the world, you don't need to take my word for it. Robert Martin writer of Clean Code:

Don't Return Nulls

Don't Pass Nulls

u/ralusek · 2 pointsr/learnprogramming

Okay, so this is a very popular book for mainly OO design prinicples:

Also very popular, though Javascript inherently uses a lot of functional programming that might be confusing if your language of choice doesn't make use of first class functions.

That guy ^ goes over like every design principle you can imagine.

I've also heard that this is great:

u/rf032 · 2 pointsr/arduino

"Clean Code: A Handbook of Agile Software Craftsmanship" is a good reading to improve ur programming skills to organize ur code and make it more readable.

This book adds more levels to my programming skills!

u/FoolMan29 · 2 pointsr/java

This is it correct?

u/jokul · 2 pointsr/todayilearned

No, I just focus on writing code that you can understand without comments. Comments are redundant, prone to being out of date, difficult to manage when picked up by somebody else, and clutter code. If you can't understand a method in 5 seconds without comments, then you should almost certainly refactor that method. This is an industry standard:

Comments cause lots of problems. That's not to say comments are always bad, but heavily commented code is more suitable to small projects where you need a quick throughput rather than large maintainable software projects.

u/kitsune · 2 pointsr/programming

Some books I enjoyed:

The Algorithm Design Manual by Steve S. Skiena, $61.15

Real Time Rendering, 3rd. Edition by Tomas Akenine-Moller, Eric Haines, Natty Hoffman, $71.20

Structure and Interpretation of Computer Programs, by Hal Abelson's, Jerry Sussman and Julie Sussman, Free

Clean Code by Robert C. Martin, $37.85

u/Sawta · 2 pointsr/linux

It can also help immensely to help future you, as well as others, if you create clear, concise variable names as well as stick to a strict set of naming conventions when you are crafting programs that may need to be tweaked months, or years down the line. I'm sure this seems obvious to a coder at your level, but so many people seem to overlook this important fact.

It bothers me greatly when I think back to some of the classes that I was taking in college (only a few years ago), where we were encouraged to use variable names like "x" or "string1".

Edit: If you haven't read it already, I would recommend checking out Clean code by Robert C. Martin; I found it to be a pretty fun read with some accurate, real life examples.

u/pi_guy10 · 2 pointsr/sysadmin

Thank you. Working my way through "Clean Code" by Robert Martin (

That book will be next on my list to read.

u/aaarrrggh · 2 pointsr/learnprogramming

So a lot of these ideas come from the "clean code" book by Bob Martin:

He argues in the book that comments are more harmful than helpful over time. The primary reason for this is because people often dive into code, sometimes vaguely reading the comments or even reading them properly, but then make changes and forget to update the comment, which leads to comments that are misleading. The common phrase we use in work is "comments are lies".

Another argument is that not writing comments forces you to write code a certain way, that through necessity needs to be easier to understand. This is commonly referred to as "self-documenting code".

I actually used to dislike this rule when I first started working at my current place, but now I love it and whenever I see code that has lots of comments I groan a little...

In terms of how you go about writing code that is easier to read - often small refactorings can make a big difference, and often times the place where you'd put a comment is a clue about something you could do to refactor some code. Often this can just be better named variables and function names. Sometimes you may find a block of code that you'd stick a comment around - could you extract this code and give it a function name that explains what it does?

If you work in this way, the code tends to document itself, and over time you find you don't really need comments so much.

u/rlfx · 2 pointsr/androiddev

Pleas read this book. It will help you to write better code without so many lines.

u/zach2good · 2 pointsr/AskProgramming
u/rm1618 · 2 pointsr/node

Two ideas: first is on crafting code; the second, on fullstack.

Input from programming legends on practices for writing clean code, including evolving code and code smells as indicators that things are not right in the code.

Clean Code: A Handbook of Agile Software Craftsmanship

This nonsense book gets right into initial decisions, sample application features, and architecture diagrams. Clarity is a good thing (measure twice and cut once). Developing on AWS is awesome and you are entitled to a free account for one year while learning AWS: AWS Free Tier.

Full-Stack JavaScript Development: Develop, Test and Deploy with MongoDB, Express, Angular and Node on AWS

(sp and added info)

u/setasensei · 2 pointsr/learnprogramming
u/ghapereira · 2 pointsr/C_Programming

Most places really do have coding standards. Some will also use standards from other companies as a basis, such as Google. If you want a deeper discussion on that, Clean Code will offer a good one.

u/RitchieThai · 2 pointsr/AskReddit

Ah, a fellow craftsman of code.

Have you read Clean Code? That book changed my life, and it interestingly suggests that often, comments aren't actually a good idea. There are exceptions.

Consider looking into it.

I haven't actually finished reading it, but I read a good deal of it.

u/gsaslis · 2 pointsr/devops

I would recommend the Continuous Delivery book ( as a starting guide for what you need to do on the CI/CD front.

It doesn’t go extensively into testing, which is basically your safety net. The Clean Code book ( is a good start here.

On the whole Agile Software Development methodologies front, it’s important to understand some principles behind each framework. I’ve found this book useful on that regard:

I know this might sound overwhelming, but so is what you’re describing... : ))
Reading books is an investment that will pay off on this journey you are setting on.

Good luck!

u/Parlay_to_throwaway · 2 pointsr/learnprogramming
u/Yevon · 2 pointsr/neoliberal

I recommend reading Clean Code if you haven't already.

Otherwise you need to be more specific about the question and how you solved it.

u/grandslammer · 2 pointsr/csharp

Thanks, but this is one 7.5 hour course and does not seem anywhere near a complete path to being job ready.

I have a Udemy account and would buy Mosh's courses on Udemy if I thought that they would form a concise package when put together. I would supplement this learning with books if necessary - specifically the following:;amp;colid=1IRAIWB2MBRLH&amp;amp;psc=0&amp;amp;ref_=lv_ov_lig_dp_it;amp;colid=1IRAIWB2MBRLH&amp;amp;psc=0&amp;amp;ref_=lv_ov_lig_dp_it;amp;colid=1IRAIWB2MBRLH&amp;amp;psc=0&amp;amp;ref_=lv_ov_lig_dp_it

But a course where everything fits together (such as a bootcamp I can't afford) is really what I'm looking for.

u/crooks5001 · 2 pointsr/learnjava

It's a book/pdf. It's available for free with a little searching but I am on my phone so I'm just going to throw the amazon link your way so you can at least see what it is, who the author is etc...

u/jl1159 · 2 pointsr/cscareerquestions

Not sure if it exactly follows this situation, but one of the best books I've read - helped me develop some good habits. Highly recommend.

Clean Code: A Handbook of Agile Software Craftsmanship

u/crookc · 2 pointsr/golang

Have you checked out Robert Martin's 'Clean Code' book and/or videos?

I've found Martin's material to be very helpful in actually identifying the attributes of clean code (and conversely, code smells). His examples are all in Java, which would be good for you, given your Java background. Despite his focus on Java and OOP more broadly, I think the fundamentals of clean code are language agnostic and there is plenty of carry-over to Go. He starts with rules around naming things and moves all the way through higher level design principles.

Fair warning though -- Martin goes totally overboard with props, green screens, theatrics, and astronomy history lessons in his videos. The book is more concise, but I'm a better visual learner, so after reading the book I started going through the videos.

u/xiongchiamiov · 2 pointsr/learnpython

Your comment was removed automatically by the reddit spam filter because you used a Google redirect link instead of directly. Make sure you visit the page first before copying the url, as Google likes to pollute search result links like that.

u/my_password_is______ · 2 pointsr/learnprogramming

this is a free python book

figure out how to rewrite all the programs to use java

especially chapters 11 through 17

see if you can find an inexpensive version of this book

read it, learn it well

u/CodeTamarin · 2 pointsr/gamedev

You always want processing. You may or may not need graphics. I saw you say you liked fighting games. You'll need a decent rig with some capable graphics.

You wanna dev?

First, yes you need a machine, a decent one. Do you want to build it? Yes , but if not then check these out. I suggest getting a workstations because they're built for productivity. However, they're expensive.

Also, I'm not sure you should commit to a desktop. Two words: Game Jams. You might want to take part in communities involved in game making games. For inspiration, mentorship and just overall fun. If you're not familiar, games jams are when developer enthusiasts get together and build a game over a period of time. The games tend to be simple and set around a theme for the event.

In which case, look at some cool laptops. The reason I suggest getting a gaming laptop is that it will have the graphic card you need, it doesn't need to be high end, just good enough to not be a toaster. Also gaming laptops tend to be more powerful.

So from a dev point of view, they're pretty solid. Personally, I prefer workstations. If you asked me, I would get a workstation with a video card, but those are very expensive and maybe when you master your craft you can drop some real cash on it. You're new. So don't spend too much, in case the entire thing doesn't jive with you. Worst case you get a decent gaming laptop to play MK at the coffee shop. (Don't laugh, I used to play Street Fighter at a coffee shop, it's a nice vibe!)

Also, I would also check out Your city or area might have groups dedicated to building games and maybe you can learn with another person. From a professional point of view, there's a lot of value in learning to work with others.

So you got your hardware, now for software.

You will likely want to start building stuff. But you're going to need some baseline stuff.

So, I say go with Unity, long term. However you need to get to a place to understand unity. So... you're going to need to learn some coding. To at LEAST be comfortable with code. I say learn the basic and intermediate stuff first then jump into Unity. If you're feeling bold you could also do the advanced.

You will need only Visual Studio and make sure during the install you ask to include Unity.

Finally, you should read Clean Code. Write good clean code. Future you will thank you.

Now, you gotta be productive.

Set up time to do what you want to do. One or two hour blocks. Commit to them. Log that time. Also, get open office, or some other equivalent and start organizing your workflow. as a develop you need purpose in your tasks. So outline your tasks. Develop you "method" for working. Maybe you like self imposed crunch where you just throw on music and go. Maybe you prefer small bursts of productivity. Whatever it is, figure it out.

Journal your work. Go back and read it occasionally. Take non-digital notes on important stuff you learn. Writing helps with retention. You have two processes you need to flesh out.

  • Your development process. How something gets built, tested and delivered.
  • Your Creative process. How you come up with a game idea and flesh out if it's good.

    You're going to need to get a good sense of how to build a proof of concept. This will help you "feel out" your game's mechanics.

    Over time, you will need to explore more advanced idea in computer science like data structures and design patterns... but for now, focus on getting comfortable with code, debugging. Hell, even make a console app text adventure game. Start there. Then get more complexity. The idea here, is to take your time, be diligent and stick to it. Slow isn't bad, not completing is bad. So take your time and good luck!
u/forthesailsofnight · 2 pointsr/csharp

This book explains fairly well what many professionals consider 'clean code'.

Stay true to OOP and keep in mind the writings of this book, and i think you will avoid most major setbacks.

u/jj2parkie · 2 pointsr/manga

Probably. It might take some refractoring, but you would need a SaaS like Parse to handle the cross platform sync. I never tried Parse, but I don't want to since it costs money after a certain quota. I've heard some horror stories of independent developers messing up their Parse and blowing through their quota as they failed to put a kill-switch.

Same. I started this project around November to learn Android development. I have a year off before I start college, so I thought of learning some software development. My only experience at the time was high school computer science using C#, so even if you are learning you can contribute. :) Even if it's intimidating you can contribute by submitting issues and such. I contributed to a small database library which was over my head, but I browsed the source to find out how to do something, found an typo in the SQL, and submitted an issue explaining the problem and how to fix it: he forgot a letter.

Although I started learning programming in 2014, if you need any advice on learning Android development, you can PM me. I can provide a list of books you can find online which are helpful for learning Java:

  • Effective Java

  • Advanced Topics in Java

  • Clean Code

  • Design Patterns

    All these books are sectioned such that you only need to read parts you want to, so they are very good references. These books really helped in knowing the syntax of a language and knowing how to use the language which I found was very important for a project of this scale. My first version of it was so hacked together that it was impossible to refractor to add new features. These books really helped for the second version even though I couldn't apply what the books advised effectively.
u/36_24_36 · 2 pointsr/cscareerquestions

Are you referring to this?

u/slappingpenguins · 2 pointsr/learnprogramming

Buy Clean Code and read it before going to bed, or during lunch hour

u/balefrost · 2 pointsr/AskProgramming

Heh, sure.

A lot of people are fans of Code Complete. I tried reading it after being in industry for a decade, and I found it to be very dry and boring. The general consensus from people that I've talked to is that it's more useful when you're just starting out. Maybe I just came to it too late.

A better book (in my opinion) in that same vein is Clean Code. Clean code is shorter, more focused, and has better real-world examples. It feels less "complete" (hue hue) than Code Complete, but to me, that's a strength. As a quick point of comparison: Code Complete devotes 32 pages to the chapter on identifier naming; Clean Code devotes just 14.

I got a lot out of Design Patterns. I seem to recall that the pattern fad was in full swing back when I read this in 2005-ish. I think I had independently discovered some of the patterns already at that point, but this book helped me to codify those ideas and also showed me some new ones. Some of these patterns are now seen as antipatterns (I'm looking at you, Singleton!), and all of the patterns have an object-oriented bias. But there's still something useful in the pattern language, and this book is a reasonably comprehensive start. The book is somewhat dry, and some people report that Head First Design Patterns is a gentler and friendlier introduction. Head First Design Patterns hits the essential patterns, but misses a lot of the less popular ones.

Eventually, you'll need to work in a codebase with some technical debt. Maybe it's debt that somebody else put there, or maybe it's debt that you introduced. Working Effectively with Legacy Code is still my go-to recommendation. It defines technical debt as code that is not under test, it introduces the idea of "seams" that you can use to pry apart code that's too tightly coupled, and it then provides a cookbook of specific scenarios and reasonable approaches.

If you're looking for thought-provoking videos, I recommend anything by Rich Hickey. I don't know if I've watched all of those, but I remember good things about Hammock Driven Development and especially Simple Made Easy.

Get comfortable with a source control system. I didn't use source control in college, since it wasn't needed for any classes, and that was a missed opportunity. The whole world loves Git, so you'll probably want to learn it if you haven't already. But I'll also toss out a recommendation for Mercurial. I haven't used it in years, but I remember finding it to be quite good.

Good luck!

u/gin_and_toxic · 2 pointsr/webdev

Some highly recommended books:

u/TartarugaNL · 2 pointsr/learnpython

This great book hammers the point home that, as a programmer, you are an author. So I'd say your education and teaching experience are an excellent starting point. Read the book and be prepared to reason about why you care about code quality. Any potential employer who cares about the future of their business should pick up on this. Be upfront about your (lack of) experience and show that you want to learn. Work on a portfolio of personal projects: noone expects a newbie to have indepth library knowledge, but experience does count.

u/TangerineWaves · 2 pointsr/learnprogramming

I like Clean Code by Robert C. Martin.

u/hugthemachines · 2 pointsr/AskProgramming

I would recommend reading Clean Code. It is a good, easy-to-read book about how to write quality code. It can help you a bit for all your languages.

Other than that, perhaps you could helpan open source project? Then you get real coding practice.

u/ynot269 · 2 pointsr/learnprogramming

Python is great for intro, I say keep at it.
Definitely pick up some books or youtube tutorials if you're struggling with certain concepts.

If you're worried about your code being messy, check out pep8 it's basically a formatting guide for python.

And to take it a step further check out [clean code] ( its a little thicc, but it does wonders for code readability.

Also recommend once you get the hang of python, check out Java. IMO it exposes a lot of those underlying concepts more so you'll understand some of the underlying mechanisms in what you write.

Note that rarely using comments isn't necessarily a bad thing

take a look at this


#return the date of birth for a given person


Which one reads better?

You'll learn this if you read Clean Code, but code is for humans. What you write will be read by humans, it gets compiled down / interpreted into machine language for computers but as far as anyone seeing your code it will be humans.

edit: forgot about md formatting

u/jacobisaman · 2 pointsr/learnpython

I would recommend reading a book like Clean Code. It talks about writing high quality and structured code.

u/CaffinatedSquirrel · 2 pointsr/learnpython

Clean Code: Clean Code

Clean Architecture: Clean Arch


Just picked these two up myself.. not sure if its what you are looking for, but seem to be very valuable for software design as a whole.

u/ScreamingGerman · 2 pointsr/coding
u/futureisathreat · 2 pointsr/cs50

My ultimate goal at the moment is to move into a digital nomad type role doing mobile development, preferably for Android.

So, my invisioned path from here is to buy or download some books on Android development and start learning. I've located what seems like a good source (of sources) for learning about Java/Android here, (taken from here)though I don't know because I haven't the links yet.

What is a good (and free) Java / Android Development courses online? Anyone have an opinion on Google's?

Does this path seem good? Should I be considering Java and Android Development the same thing? Thank you!

u/the_real_chef · 2 pointsr/SoftwareEngineering

Clean Code Books:

u/Ilyketurdles · 2 pointsr/cscareerquestions

It might be. There's the issue of making things work, then the issue of writing clean maintainable code that others can understand. A good engineer needs to be able to do both. For something like Java or C#, check out SOLID principles. There's also a book called Clean Code which might be helpful.

u/RedScud · 2 pointsr/argentina

Jajaja salta a la vista no?

Comentarios igual te los paso... pero que te encuentres un metodo asi de jeta llamado ersteIndexprufung ponele en vez de firstIndexVerification.

Ya vi cosas como var variavel1 , function asdfg

Ya que hablamos de todo esto:

u/threedaysmore · 2 pointsr/ProgrammerHumor

I'll start by saying if you haven't read Clean Code, then it's a great place to see questions like your answered with examples. It gets a little too in the weeds for some people at the end, but the first several chapters are great for explaining how, why, and when to break things up.

What a lot of it comes down to for me (and there are different opinions on what "clean" code looks like or should look like, it's somewhat stylistic) is readability.

No matter what app you're writing, with a little bit of business/domain knowledge I should be able to look at your code without having seen it before and be able to understand what parts of the code are responsible for what logical operations so that if the requirements have changed or a bug was found I should know right where to go.

I made a small example while nomming some lunch (forgive me for typos or obvious errors lol). The example is a Cash Register app that is responsible for totaling the sale amount given a list of items.


Here is the orignal code | Here's the refactored Specifically looking at the CalculateTotalSale methods....

So in a small trivial program it's not as easy to see the benefits, but in the refactored version the total sale logic has been broken up into methods. This way, lets say there's a bug in how we're calculating taxes (in a small app like this they're probably wouldn't be, but in an enterprise POS app that's in an international market tax calculation can be a pain) we've made several ways to track down where taxes are being done. We can look at the usages of _taxes to see where it's being modified, and we can look at CalculateTaxes() method since that's where all the tax logic should be. If we find that tax logic is not there, we should either move there, or consider a small change in design to make it flow easier.

Also we've left the CalculateTotalSale method open for extension as well. Noted by the comments, if the business wanted us to write coupon logic we could put it in it's own method and go from there. We've left a pattern for the next person to follow, they'd be able to get into this code and get to work pretty quickly. Patterns do change though, but since we've followed some fairly fundamental designs of class structure it'd be easy for someone to change the pattern if they needed to. They won't have to look all over the code for pieces of logic if we've grouped it well.

All that being said, the first example still works fine and gets the job done, the discussion above is more of engineering vs programming. Just my two cents though! Sorry if I've made any obvious errors or didn't explain this well!

u/Bolitho · 2 pointsr/csharp

Ok, then I would suggest the following ones:

  • Head First Design Patterns
  • Clean Code

    Besides Books you can also find good artciles on the net about OOP basic principles like SOLID.

    Actually I loved the Design Pattern book for showing me, that the basic principles are really the core of OOP. Of course they rely on the building blocks (Abstraction, Inheritance and Polymorphism), but they show you, how you should use those and make advanatge of them in order to build clean, resuable and maintable software. The latter on of the books focuses more on those principles, which is also nice.
u/guitarino · 2 pointsr/javascript

I really recommend a book Clean Code by Robert C. Martin. It can really help you understand how to write clean code, which you can use and improve right away.

u/jakeinstein · 2 pointsr/gamedev

Hi here's the link - it has made a huge difference in how I code. If you can get your hands on the video that's even better. They are hilarious.

u/vinnyvicious · 2 pointsr/gamedev

Have you ever heard of the open/closed principle? Or the single responsibility principle? Or Liskov substitution principle? All three are being violated. It drastically reduces the maintainability and extensibility of your code. I can't swap serializers easily, i can't tweak or extend them without touching that huge class and it's definitely not the responsibility of that class to know how to serialize A, B, C, D, E and the whole alphabet.

I highly recommend some literature on the subject if you're curious about it, it would drastically improve your approach to software architecture:

u/iheartthejvm · 2 pointsr/ProgrammerHumor

This book changed the way I did things massively and may help you:

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)

u/invictus08 · 2 pointsr/flask

First of all, applause for the great start.

Here are some criticisms/suggestions I would like to offer. Keep in mind, I am not assuming your level/experience as a software developer:

  1. Functions with smaller size. You see, most of the functions that you have written is lengthy because of the sql statements. Here comes my second point.

  2. Separate business logic, application code, data storage related stuff etc. Keep things modular. That separation is important because you want things to be maintainable and reusable. Your code should be open for extension, but close for modification. If that does not make sense to you, that's perfectly fine, just start from this

  3. On that note, since you are using flask, might I suggest using flask-sqlalchemy instead of sqlalchemy? You may like it better. I know you have mentioned

    &gt; I force myself to write raw SQL Request to get better with SQL

    while that is commendable, it is not really a good idea to write raw sqls in production code if there are ORM library alternatives available. Remember, it's not always you that is going to read/modify the code. While ORM syntax will be fairly universal, your style of writing SQL may vary starkly from other people - which is what creates confusion and lets errors sneak in. Even if you want to do that, maybe keep the raw sql in separate modules (point 2).

  4. Instead of computing everything and then sending the result along with the page, maybe create api endpoints for specific sections; render page with bare minimum info and from the webpage make multiple calls to update the page sections when required. This way, it will be far more responsive, user will not be waiting for you to finish all the computation and if you detect any change in any section of the page, you can just update that particular section with an appropriate api call, thereby avoiding a whole page reload. Design choices.

  5. PEP8. You don't have to blindly follow every rule - just make sure you understand why those rules are there, and that if you are breaking any, you know that it is absolutely necessary for accomplishing what you want. Again, what you want may not always be what you actually need - so be really careful.

  6. This is something I wish I knew earlier - Design Patterns. Without going into much details, I would recommend reading these books to start with and really understand instead of memorizing:
  7. Documentation is also important. Follow the good practices there. A remarkable reference would be Ken Reitz's Requests library.

    Finally, remember that all these are just suggestions, and you may already know them. You will decide which ones to take and which ones to leave behind based on your situation.

    Again, great job (I also learnt something from this). Just make sure you keep running.
u/minond · 2 pointsr/webdev

Not really related to mobile development, but he should still really enjoy these if he hasn't read them already:

u/notThaLochNessMonsta · 2 pointsr/javascript

There are more than 356 people in the programming community. This isn't Mumps.

I agree most of the time that early returns are better. But this isn't proof that "most of the programming community agrees". You realize that there is a substantial amount of developers who believe in only 1 return per function, right? Something that is evangelized in Clean Code.

u/bluefisch200 · 2 pointsr/ProgrammerHumor

Please consider reading this 😉

I know you are the sole developer but still...that is just confusing.

u/MoreCowbellMofo · 2 pointsr/java

&gt;How valuable is an Oracle cert?

No more than any other online course from a respected institution such as google, say: or one of the online courses available at MIT/Stanford.

&gt;What else should I look into to boost my repertoire?

See if your university has any business partnerships you could do a 2-3 month project for. I worked with one of the university's here in the UK as part of a business/university partnership and that gives the students real world experience and us some free work. Win-win if the project is completed.

Sorry - mostly UK (amazon) links :)

TDD -, Video by Trisha Gee whos fairly well known for speaking on this stuff: (some very handy shortcut keys in the video and a good outline of some of the tools available to you).

Clean Code - (by "Uncle Bob")

Design patterns -

Learn to use shortcuts in Intelli J to speed up your ability to generate/refactor code:ção/dp/1849699615/ref=sr_1_1

Also Jetbrains does good newsletters (curated by the same lady that made the video above under TDD) sign up to stay up to date with interesting/relevant blogs/articles/industry news

Github -

Bash Commands -

XP/Scrum/Kanban development process - the way we work

Trusted developer blog on various engineering topics

Interview Prep

Hint: the above books are likely to be available at any academic library. If not, request them. you likely only need to read 33-50% of them and you'll be golden. I imagine you can likely get hold of electronic versions of these books as well.

The best thing you can do to prepare yourself is to start practising developing projects... get them up on github. it could be a website, a desktop application/game/tool, a demo of sorting algorithms, a web service... literally anything. Fork others' projects, code a feature request and create a pull request back to the original repository/codebase on github. Just build something rather than nothing. Anyone can do the latter. There's so much more opportunity now that we have github available. Think of any thing you might be interested in working on and someone, somewhere has likely already got a project underway in that area, and you're free to submit a pull request to their repository at the click of a button. This wasn't really possible 10-15 yrs ago.

The simple answer is there's so much to know, you just have to find what your interests/passions are and follow those as much as possible.

No matter how good you are at what you do today, the tools will be different tomorrow and may even depend on the industry you enter: AI, web services, blockchain, computer vision, robotics? The list is long and each one requires you to be highly trained (over many years) before you're considered any good at it.

Just try to learn what you can. Find something that genuinely interests you and study it until you become a trusted authority on the subject, or you find something you're more interested in instead.

If you have any ideas for the type of area you might be interested in put them up here and perhaps someone can point you to a relevant project? "Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats."

u/async2 · 2 pointsr/Physics

Maybe check the clean code handbook. Already the first pages describe what many people do wrong which leads to crappy code. You can also find it on the interwebs.

u/AnnoraxD · 2 pointsr/java

Good job! Copying existing game ideas is a perfect way to learn

Some recommended reads I had saved as bookmarks if you want to dig even deeper into game programming:

Game programming patterns

Goes deep into all the different patterns of writing a good game engine. Written by one of the devs at EA. There is a free web-version if you scroll down on first page.

Game mechanic explorer

Lots of small snippets and explanations on common mechanics, like bullet trajectories etc. Only for 2d games but much easier to digest then the patterns-site.

A* introduction

A* is a fun algorithm to implement

Clean code book

This one is a must, a book you might get the most out of when working with other people but if you wanna get thinking in the terms of maintainable code and what will be expected of you at a real workplace, take the advices it gives to heart :)

And a tip for a potential next project:

One of the first games I did was a clone of Bomberman. The graphics can be pretty simple but you get to dig into cool stuff like (simple) AI with pathfinding and you can make a very simple multiplayer game out of it that isn't that lag sensitive

u/SunshineBiology · 2 pointsr/dailyprogrammer

Hey! I'm not a senior or something but I have a tip for you (might sound a bit contradictory to what you've been learning in school/uni). I would try to cut down on the comments.

A lot of your comments are just restating exactly what the code says. For example

//Create an array of four structs - one for each tax band
struct taxBand taxBands[4];

Everything your comment says is already said by the code itself. The comment thus does not add meaningful information and just clutters up the code.

Even worse, you add maintenance problems to it: if you have to change the code in the future (let's say we get a new tax scheme and now there are 5 tax brackets), you have to change the code AND the comment. If you forget this at some point (happens easily), the comment will now even give wrong information about the code.

Generally, try to use comments not to describe code, but to describe your intention or very tricky parts about your code. You can also refer to the Google Code Styleguide if you have further interest. Clean Code also has a good segment about it.

The rest seems fine. As an additional exercise, you should probably try not to hardcode going through the taxbrackets, but try to write it in a more general way. At the state your programm currently is, if new tax brackets were added, you would have to write (copy-paste) additional for-loops as you did in

//If the income is more than the upper limit of band 1, but less than band 2, work out how much income is taxable and multipy it by the band 2 tax rate. Add the result to the tax variable
else if(income &lt; taxBands[1].upperLimit){
tax += (income - taxBands[0].upperLimit) * taxBands[1].rate;

You can try to rewrite that section so it does not depend on the total number of tax brackets :)

If you have questions, feel free to ask!

u/KoleCasule1 · 2 pointsr/csharp

This is the third book suggested that was written by Uncle Bob.

Can you maybe explain the Difference between:

Clean Code , Clean Architecture and Clean Coder. All books by Uncle Bob

u/iissqrtneg1 · 2 pointsr/fffffffuuuuuuuuuuuu

Make This your bible and you'll never think about writing another comment. And you'll never have that problem again.

u/Pet_Ant · 2 pointsr/programming

Clean Code
Refactoring into Patterns
Both talk a lot about them but do not enumerate them authoratatively.

u/renang · 2 pointsr/PHP

From one of my favorites books, Clean Code: A Handbook of Agile Software Craftsmanship:

&gt; Others who see that commented-out code won’t have the courage to delete it. They’ll think it is there for a reason and is too important to delete. So commented-out code gathers like dregs at the bottom of a bad bottle of wine.

u/oowop · 2 pointsr/learnprogramming

I'm by no means an experienced programmer but one of the books I have queued up to read which is recommended in the sidebar and many threads is Clean Code: A Handbook of Agile Software Craftsmanship

u/guifroes · 2 pointsr/learnprogramming


Looks to me that you can "feel" what good code looks like but you're not able to rationalise it enough for you to write it on your own.

Couple of suggestions:

When you see elegant code, ask yourself: why is it elegant? Is it because is simple? Easy to understand? Try to recognise the desired attributes so you can try to reproduce on your code.

Try to write really short classes/methods that have only one responsibility. For more about this, search for Single Responsibility Principle.

How familiar are you with unit testing and TDD? It should help you a lot to write better designed code.

Some other resources:

u/Gawwad · 2 pointsr/battlestations

Writing bad code is fine when you're starting out, but being able to write code that you and others can read after it's complete is not an impossible feat for a beginner. To get a start in writing good code, read Clean Code. I would suggest reading it after your (/u/Zeno_Zaros) first semester when you have some idea about programming.

u/teresko · 2 pointsr/PHP

What you have to realize is that framework is a tool for development. It lets you code pages faster, by already have done the "mindless tasks" (like creating user authentication or routing the requests) and letting you focus on the parts that matter.

But there is a cost - performance. Unless you really suck at writing code, framework will make you application slower, because of all the generalization and "works for everyone" approach.

If you have an existing site, just slapping on a framework will gain you nothing. If you want to rewrite you application from scratch, then framework will let you complete that in less time (if you already know how to use said framework).

If instead you want to expand or optimize the existing functionality, you should focus on refactoring and profiling your existing codebase. If that is the case, here are few books which would help you with it: Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin , Real-World Solutions for Developing High-Quality PHP Frameworks and Applications by Sebastian Bergmann and Refactoring: Improving the Design of Existing Code by Martin Fowler. Said book will not give you clear rules for "how to do this", but instead will explain you the direction in which you should aim.


P.S. in my personal opinion , CodeIgniter is one of the worst php frameworks out there, with unreasonably high popularity.

u/haywire · 2 pointsr/PHP

Do not comment the hell out of your code. Well written code should be self explanatory. Do not comment what, comment why.

Read this book:

Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)

u/negative_epsilon · 2 pointsr/learnprogramming

At first, just code. Your code will suck, but it's okay because you're learning.

Then, once you have a good grasp of programming, read


You can probably find them for free online.

u/jonathan-fulton · 2 pointsr/SoftwareEngineering

A lot of the tips, including this one, come from Uncle Bob's "Clean Code" book. I recommend picking it up for a much more thorough examination of Clean Code principles.

There are times when a 4 line restriction on function length is burdensome, but it tends to be a good guideline. Language also matters. I've found it's harder to adhere to the 4 line restriction in Node than PHP for example just based on typical syntax for the language.

u/NoahTheDuke · 2 pointsr/Python

Read Effective Python and Clean Code, in that order.

u/ldelossa · 2 pointsr/golang

What about some classics like Uncle Bob talks?

A lot of good design focuses on decoupling and creating components which work together but separately also.

Id first look into language agnostic design principles such as SOLID (golang)

A good book will help.

I still keep a copy of the Gang of Four book at arms reach even tho the popularity is dwindling as OOP is not topic of most convos today. However when dealing with DI and sharable components in Golang, i find myself still falling back to abstract factories patterns. Its a good breathe of knowledge to at least glimpse at the patterns here:
Design Patterns: Elements of Reusable Object-Oriented Software

Once you get thru these topics, you can start picking up what I consider the "hot" architectures of today:
Microservices, event based systems, domain driven design, event sourcing, and architectures aiding themselves to functional programming.

I really enjoy reading Martin Fowler blog posts:

He covers a lot of these topics.

PS: maybe a niche and a personal favorite of mine but ive learned ALOT by researching the different types of kernel architectures. Nothing really geeks me out like those topic, but not for everyone.

A fabulous free course exists on these topics:

u/Cilph · 2 pointsr/explainlikeimfive

It is good practice to have variable names with clear naming that accurately describes what they are for. What you're suggesting results in variables with absolutely no name whatsoever. (array[0], array[1], array[2] are hardly descriptive).
Moreover, good programming means dissecting your problem into small easily managed chunks. So small, clear functions or objects. If you have a lot of variables in these, you are doing it wrong.

u/DestroyerOfWombs · 2 pointsr/learnprogramming

A general rule is that classes should represent one object (as an abstraction, not Object as in class instance), and functions should do one task, and it should be understood from name alone everything that they do. If a class is convoluted, it means you probably have more than one class pigeon-holed into a single class. Break it up into separate classes. Same for functions. If a method is too complicated, it should probably be at least two functions.

It might seem crazy to break up a 5 line function into 2 or 3 2-line functions, but you'll be better for it when you return to your code in a month and have to make sense of it again. Hell, it might help in a hour when you realize that one of the jobs performed in that function needs changed, you won't have to weed through a dozen other functions to find the line that you need to change.

Try giving Clean Code by Robert Martin a read. It is a must read IMO, because the suggestions in it will make you a better programmer overall, not just in one language or methodology.

u/ChamesJucks · 2 pointsr/java

Start with Spring Roo + Clean Code:

u/AceBacker · 1 pointr/javascript

All I care about is clean code. Code that is easy to read and change. If a framework helps you do this fine.

If you haven't heard of Uncle Bob check this out:

Or if you prefer his goofy video's:

u/navyjeff · 1 pointr/Python

Take the period off the end of the link. link fixed

u/jabbalaci · 1 pointr/Python

Link correctly: Thanks, anyway.

u/fatalfred · 1 pointr/Python

A "." has been left in the URL. fixed link

u/punkdgeek · 1 pointr/Python

You should probably be a little more disciplined when writing your code, this book will help with strategies on writing good code: The author discusses Java, but the same techniques apply to python. Obtaining the mythical 100% code coverage with unit test are a good goal, but writing easy to understand, small functions that are as atomic as possible will let you code your "stream of thought" by segmenting each idea into smaller ones that you can name, keep track of, and test. Don't forget to refactor while you still know what your code means; make it work, make it right, make it readable.

u/thestandardtoaster · 1 pointr/PHP

There are lots of books on this topic one I like is clean code

u/Shen_an_igator · 1 pointr/gamedev

&gt; Planning as much as you can before writing code

To add to that:

  1. Learn UML and how to draw activity diagrams. It takes forever at first but will cut your coding time down drastically + create code that is sensible instead of spaghetti code.

  2. Learn the conventions and symbols of UML. Not all of them are necessary, but the basics download here for free. Doesn't matter how long you worked in the industry, lacking this knowledge is detrimental to yourself, your employer, your project, and other coders that have to figure out your shit.

  3. Learn to cleancode before you tackle bigger projects (if you can't read your code like a book and you use variable names that are vague, your code is a mess) sadly I didn't find a good english source, but this book is the anchorpoint

  4. Learn how to create a game-design document. Fix what you want in your game. Once the document is finished, it's immutable. Until the game is done.

u/Kummo666 · 1 pointr/learnprogramming

One that I'm currently reading and it's pure gold is Clean Code.

u/Midas7g · 1 pointr/gamedev

The advice on the last line is called The Boy Scout Rule from Clean Code by "Uncle" Bob Martin. It has made a huge difference in the quality of my code.

u/_RealBear_ · 1 pointr/learnprogramming

I recommend reading book called clean code. Answers you have gotten here seem to help only with this specific task. What you need to get better at is how you think about code in general.

u/apieceoffruit · 1 pointr/ProgrammerHumor

Oh god where to begin?


Well I Like to think there are level of programming understanding that are relatively tiered.

Tier 1 - How to Code

This one is tough as there is no real definitive best answer. My personal primer of choice is

  • Sams Learn Java in 24 hours.

    &gt; Fyi - , that is not "in one day" that is , in 24, 1 hour sessions equating to a hypothetical 4 college lectures a week lasting a month and a half of intensive training. A huge amount of homework is required to accompany that primer.

    so now you can write an app, what next? well. to finish the thought:

    Tier 2 - How to Code...

    so other programmers don't want to hit you over the head for each line in your longest function screaming CYCLOMATIC COMPLEXITYYYY


    Here we talk about how to program
    properly* You want to be looking up Uncle Bob . Head over to


    and check out his video form of his famous book:

  • Clean Code....then buy that book.

    Now you should be writing code that doesn't make other programmers eyes bleed.

    Tier 3 - How to Code..To Solve Problems

    Here we talk about design patterns. Now, you will bump into a lot of debate over their value but...that is stupid. that is like some people saying all carpentry should be done with a saw and another group saying carpenters should never use a saw. Design patterns are names for recognised ways to solve problems you will hit every day in your programming. They may not always work in your case but at worst they will have you thinking around a problem better.

    For a primer, check out:

  • Head First: Design Patterns

    In fact the entire head first series is great, It is like the For dummies series for programming principles. Great for morons like myself.

    With that read, get the real design pattern book:

  • Elements of Reusable...

    Don't expect to actual understand almost any of this. I read that book cover to cover and it didn't actual click for me till it slapped me in the face when i was in the real world developing business tier applications. Although having read it so many times meant I new which pages to flip to when I was ready.

    Tier 4 - How to Code... For Users


    This is a whole different kettle of fish. Now you may have written the perfect app to do X with only two buttons, you will find quickly that users are adept at licking the buttons in just the correct order to cause your application to explode. You need to program applications so the cast of jersey shore can use it.

    I am a fan of the blog:

  • Joel on Software.

    Joel (Co-founder of Trello) covers a lot regarding front facing applications and UX that is required reading...even if he a bit cavalier on his approach to testing.

    This is the next part. Testing. You are going to want to Learn about Defensive Programming andTesting. There is a wealth of tutorials over on pluralsight for these.

    Tier 5 - When NOT to Code


    This is a hard step to get to. Realising that copy and pasting code is GREAT!..but for the right reasons. Once you jump over the initial Copy+paste = the greatest thing in the world barrier , most developers grow a level of defiance that borders on the absurd. Preferring to rewrite the wheel instead of using ...the wheel. When you can honestly say you
    could* program it from scratch, it is perfectly okay to use libraries and apis.

    This is where I go to:


    and hit up Sacha and others. They show you fairly feature complete and interesting implementations of problems, not just the one or two lines you get from Stack Overflow. Granted this is miles more complicated but it shows not only how to do it, but how to do it right and WHY to do it right. and github of course.

    Tier 6 - Learning From Mistakes


    Now that you have climbed code mountain and are absorbing the combined knowledge of all the internet geniuses, it is time to see where you went wrong.

    Head over to


    and post you functional applications. There a number of people will politely tell you but how to do it better, general improvements in design, logic and reusability. take you through the solid principles and much more. Also..say hello to me if you like :P.

    You don't even have to learn exclusively from your own mistakes.

    check out:


    and cringe at some examples of real software....and if you don't understand why you should be cringing..learn.


    Tier 7 - How to think like a programmer

    Now things get a little bit meta. The best way to become a great programmer? don't JUST read programming. Read books like:

  • Zen and the Art of Motorcycle Maintenance

  • Don't Make Me Think

    Read anything and everything, exercise your mind. books on architecture, books on carpentry. any kind of design and problem solving with stretch your understanding of how to climb those brick walls you will hit.

    Read some of the more general programming blogs, like:


    Read anything and everything.

    Final Thoughts


    Have fun.

    Check out:


    I would also say as a personal suggestion, although i left it out of the mandatories up above as it is a bit controversial, I suggest going TDD. Test driven development. It is not for everyone, a hard ethos to get into but in the real world, in business applicable coding...a life saver. Uncle bob is the man for that again.

    Finally I am a fan of Rubber Ducking. Great way to work though problems.

    If you want some final reading, I left them out because everyone and their brother has these (and most of the above) in their top 50 programming book lists so it is a mite redundant:

  • Code Complete
  • The Mythical Man Month
  • The Pragmatic Programmer
  • Refactoring: Improving the Design of Existing Code


u/sh0rug0ru_ · 1 pointr/java

I would suggest reading these books to get a deep understanding of OOP:

  • Agile Patterns, Princples and Practices in C#
  • Growing Object Oriented Software Guided by Tests
  • Clean Code

    Here's a chapter from the Agile PPP book, Heuristics and Coffee, which gives a great overview on how to think in OOP terms. Keep this in mind: OOP is a way of thinking as much as it is a way of programming. OOP lives in the spaces between objects, in the methods, not necessarily the objects!

    Also, note that OOP is a code organization, which really starts to make sense in larger programs. I would suggest writing some larger programs, such as a contact manager, an email client, a chat application, etc. Larger programs will give you a chance to play with technologies such as databases and client/server networking. More stuff to add to the ol' resume.
u/ensiferous · 1 pointr/PHP

&gt; I don't think a switch statement is a code smell.

I'd highly recommend that you read Clean Code

To quote it on Switch statements:

&gt;It’s hard to make a small switch statement. Even a switch statement with only two cases is larger than I’d like a single block or function to be. It’s also hard to make a switch statement that does one thing. By their nature, switch statements always do N things.

Also note that a code smell is an indication that something might be wrong. Not a definite "never do this". I think you have some preconceived notions about this place and you applied those to me unfairly and down voted based on something I never said.

u/XVar · 1 pointr/csharp

&gt; This is especially important if there is a "calling protocol", like "cannot call X before Y".

This is known as Temporal Coupling, and is generally not a desirable design. You should enforce correct usage through your design, not through comments.

Incidentally this is another thing covered in Clean Code by Robert "Uncle Bob" Martin, if you haven't read it then you should, it's probably the most important book any software developer will ever read.

u/RedSpikeyThing · 1 pointr/programming

Style. After reading through Clean Code I wish there had been more emphasis on this.

u/yankexe · 1 pointr/learnprogramming

This is specific to JavaScript but I guess naming variables are the same across all the programming languages. Here's some insights from Clean Code book extracted for JavaScript.

Clean Code Naming Variables GitHub

u/TheSurrealSoul · 1 pointr/funny

At the last place I worked clean code was just how we opperated. I got scolded if I added an unessisary comment. Asking myself "is this comment need? If so, how do I make my code more readable".

I completely agree there are times and places for additional information but ideally good code is easy to follow.

a basic low level example would be holding a users hand through any decision making process.

//that means the value was true

//it wasn't true

but maybe I have been brainwashed, anyways I had this book on my desk for a few years now, its a good read and great and even though I can disagree with a few things he says its nice to have that engagement with the author.

u/IEatBasashi · 1 pointr/funny

People who are downvoting this comment need to read this book. Well thought out variable and function names can replace unnecessary comments in many cases.

u/CodeBlueDev · 1 pointr/learnprogramming

Read books like The Pragmatic Programmer, Clean Code, and The Clean Coder. You can find pdf versions of these books if you know where to look.

Otherwise, start looking into design patterns and how to implement them, read other people's source code/open source and really try to understand it, read programmer blogs (like Jon Skeet's or something), and review the code you have written and think about what you could have done different or better. And of course you need to continue programming and practicing - you'll get the most out of this if you can integrate TDD (Test-Driven Design) into your applications.

u/husky11 · 1 pointr/learnprogramming

This was also a good book for me :)

P.S. PM if you want a pdf version :P

u/Wh0_The_Fuck_Cares · 1 pointr/Unity3D

You're kidding right? That's 100% personal preference... It doesn't matter how you place the braces as long as you're consistent.

This: The Microsoft C# Style Guide. It's literally garbage unless you work for Microsoft or a company that also follows this style guide to religiously. They're suggestions by Microsoft on how to write clean code. If you want a real break down on what clean code is read Clean Code or The Pragmatic Programmer and you'll learn what things are actually worth worrying about.

u/theclapp · 1 pointr/programming

Came here to post that. +1

Also, Clean Code.

u/return-zero · 1 pointr/learnprogramming

hey sorry i wasnt able to help you out in time. glad you figured it out and got some constructive feedback. i had a sneaking suspicion it was due to a while loop. i would highly recommending reading the book clean code. it has a whole section on proper variable naming among a bunch of other stuff you would benefit from.

u/nvdnadj92 · 1 pointr/javascript

Just to throw in my two cents here, I learned how to think in terms of "clean code" after watching a set of lectures by Robert C. Martin, AKA uncle Bob. He provides an conceptual framework for how to write "clean code" and is widely accepted as the subject matter expert in the software engineering community.

I highly recommend it -- He goes over things like "how to name variables", "when to split up functions into smaller ones", "how to structure programs", etc. I'm not kidding when I say that those lectures were the most meaningful improvement I have made as an engineer.

He also has a book too!

u/both-shoes-off · 1 pointr/GiftIdeas

I'm a programmer. This is my most favorite keyboard I've ever bought. It's mechanical, but the "clickity" is perfect, and low travel (it's 69.99... and 59.99 for the one without the number pad). They list a few options, but the one's that I find great have "Kailh Latest Low Profile Blue Switches". Also the back lighting is really nice.

I don't know what language he's working with, but this book is excellent too. Many of the examples are centered around java/C#, but most concepts apply across many languages. It motivated me to explore further after reading, and to really polish up on my skill set.

u/kvlt_ov_personality · 1 pointr/sysadmin

Thank you! This is exactly what I was looking for, I appreciate the list of subjects to educate myself on.

As far as well documented, readable code - I ordered this from Amazon and I'm hoping it will help me in those areas:

u/CentralCalBrewer · 1 pointr/IAmA

Shoot - I forgot a question mark in my first comment and it got deleted, so I cut an past and the link didn't come though..

Clean Code

u/ServerSimulator · 1 pointr/Unity3D

&gt;mostly because you need to be good at a lot of mathemtics, is this true?

This is primarily for algorithms. It's pretty easy to be good at math, the hardest part I find for people who program is that they often don't think "outside the box" in breaking their program down.

I and others recommend programming in C#. You should be able to get off the ground with the following resources:

This list is for programming in general:;amp;ie=UTF8&amp;amp;qid=1453520022&amp;amp;sr=1-1&amp;amp;keywords=pragmatic+programmer;amp;ie=UTF8&amp;amp;qid=1453520045&amp;amp;sr=1-1&amp;amp;keywords=clean+code;amp;ie=UTF8&amp;amp;qid=1453520067&amp;amp;sr=1-1&amp;amp;keywords=gang+of+four

u/dreistdreist · 1 pointr/PHP

Get a copy of clean code.

I work on proprietary software, my employer would not appreciate me sharing the code...

u/tevert · 1 pointr/SoftwareEngineering

Did you mean literally Clean Code? Because that's an actual book and it's awesome:

u/nil_von_9wo · 1 pointr/salesforce

There are no good resources for Apex development IF YOU CONSIDER CODE QUALITY TO BE IMPORTANT.


What worked for me:

  1. Learn Java. SAMs Teach Yourself Java in 24 Hours is good for this.

  2. Learn Object Oriented Programming. SAMs Teach Yourself OOP in 21 Days is good for this.

  3. Learn to write proper unit tests. I learned from some Python tutorial which was written by a Test Driven Development advocate. Even if you don't do TDD, it is good to learn it because it helps you think about how to write testable code. If you want to stick with Java (might as well), you could try some of these (note: I haven't actually looked at any of them, so I can't vouch for the quality):

  4. Learn about mocking. I learned with some tutorial on Mockito (a Java library). Unfortunately there is no really good way to mock things out in Apex, but if you understand what you are doing, it is easy enough to build your own mocks even without any framework or library.

  5. Learn about design patterns:

  6. If you haven't learned about dependency injection from the above material (you should probably have learned about it while learning about mocks), wikipedia will tell you everything else you need to know.

  7. Learn about clean code:

  8. Learn to use version control (e.g. git). Atlassian's tutorial will probably teach you more than you need to know:

    After you'd done all that, then go to Trailhead and look at all the material with a very critical eye. If you can't find at least 10 flaws in every example, then probably all the code you are writing is shit.

u/lucidguppy · 1 pointr/learnpython

Step one - write a big function.

Step two - split this big function into smaller functions to make each easier to understand.

Step three - see that you're using the same values over and over - and passing them to the split up functions.

Step four - extract those common variables into a class.

Step five - decide which functions purely relate to those data types - which change the values - those become methods in the class. The associated methods to a class should really only have one reason to change.

Think of classes as full computers - that are stripped down to help you solve one problem - you feed it info - and are only given four or five buttons to do something.

Note - you don't need OOP - but you'll end up passing in the same data structure as the first argument to a set of 4 or 5 functions - C does it all the time. OOP makes it easier.

End: Go read clean code.

u/terraneng · 1 pointr/learnpython

While not Python specific (it's in Java) this book is very good. Clean Code: A Handbook of Agile Software Craftsmanship

u/nikrolls · 1 pointr/webdev

I really suggest you read Clean Code. It will change your life as an engineer.

u/ameenashad · 1 pointr/programming

Awesome. How about Clean Code by Robert C. Martin?

u/liaguris · 1 pointr/learnprogramming

Yeah I have read around 70%-80% of all YDKJS books combined .

By the way just in any case you find anything interesting and helpful (but for also copy pasting this list in the future) here are the books-site tutorials-docs that I am reading-have read-plan to read-follow :

web dev road map


css in depth (manning)

eloquent js

YDKJS (all books)

HTML5 for masterminds

dom enlightenment

high performance images

web performance in action

reliable javascript

building progressive web apps

http: the definitive guide

learning http 2

cracking the coding interview

javascript data structure and algorithms (be careful,not a good choice, it has a lot of mistakes but I find it concise)

professional git

vs code docs

Using SVG with CSS3 and HTML5

Interactive Data Visualization for the Web

refactoring ui

figma docs

react docs

redux docs

vue docs

webpack docs

clean code

design patterns

web components in action

Inkscape: Guide to a Vector Drawing Program

and many more to come .

u/fzr600dave · 1 pointr/learnprogramming

I've come across this book that helps explain readable code much better than short abbreviated code that you spend the next 20-mins working out what the hell it does.

u/tanenbaum · 1 pointr/ProgrammerHumor

If the concept of magic numbers is foreign to you, then you should probably read this. Magic numbers are just the tip of the iceberg of bad practices...

u/Vertigoh · 1 pointr/learnprogramming

Then you write crappy code. Code should aim to be self-documenting, to read like a story.

Read this, be better, you're welcome

u/chachinsky · 1 pointr/javascript

If you associate test-driven development (TDD) with learning better code design, it might help fill in any gaps you feel you have. Best to have an understanding of SOLID principles, DRY, and KISS.

Red Green refactor is a good starting point.

Though its not JS specific, anything by Sandi Metz is awesome, highly recommend her 99 Bottles book.

Uncle Bob's Clean code is a great resource as well.

u/Brocccooli · 1 pointr/ProgrammerHumor
u/the_omega99 · 1 pointr/learnprogramming
u/fgdub · 1 pointr/learnprogramming

Read the book Clean Code. It explains everything on writing readable, easy to manage code.

u/bizzard4 · 1 pointr/computerscience

Clean code is probably one of the most popular CS book. This is the kind of stuff you will never learn in school and very basic programming skill is enough to understand.

u/CoderMonkey123 · 1 pointr/AskProgramming

Clean Code principles based on Uncle Bob's book.

Links to summaries of the book's principles: Link1 Link2(pdf)

u/sew-my-eyes-shut · 1 pointr/learnprogramming

I recently finished reading this and found it to be extremely helpful.
The code examples are written in Java but its based more on the concepts of what separates good code from bad code.

Clean Code

u/ctrlShiftBryan · 1 pointr/dotnet

What I like to do is start with just one class and one method.

As that method grows to more than 5 or so lines of code, start re-factoring it by grouping lines of code together and moving them to separate methods.

As this class grows to 5
or more methods groups the methods in a way that makes sense and move those to separate classes.

I prefer this approach compared to trying to decide all the classes and methods you need upfront.

*This number can actually be smaller or even 2.

I would strongly recommend you read this book:

u/BadRandolf · 1 pointr/javascript

I'd go for method 3, though I'd write the functions differently (ex. currying a function that can return undefined is not a good idea). I'm talking about the overall approach here.

My reasoning (and some of this is subjective I know):

  • If this isn't being called hundreds of times a second then performance takes a backseat to readability, maintainability and re-usability. I'll gladly sacrifice a few cycles per second to improve any of those things. Of course none of those are mutually exclusive, you can rewrite the code in Method 3 to be a lot faster than what's written in the OP without losing any readability.

  • Each function is short, has a descriptive name and is easy to understand at a glance. When you're working alone maybe this isn't so important, but when you're working on code with 10 other people contributing it makes the whole process much easier. See Clean Code

  • You can easily reuse parts of the algorithm in Method 3 (eg. isShortMessage could be part of an if statement somewhere). The other 2 methods solve one problem and one problem only. If you suddenly find you need a function like isShortMessage somewhere you're either left duplicating code or rewriting those functions to make them more generic.

  • Method 3 is easier to debug. This is a pretty minor point and it's somewhat nullified by the function currying at the end, but it's something to think about.
u/Neuromante · 1 pointr/Unity3D

Welcome to the great world of documentation and clean code writing.

I would start by reading lean Code: A Handbook of Agile Software Craftsmanship. Look for the second edition, though. (Btw, even though it tells in the introduction that is a tough book, it is not, although maybe if you are starting from "zero" on good practices, it will have some hard parts).

From there, learn about UML and use it with (for instance) to document your code organization. Is the shit, because you need to keep updated the diagramas when you change something, but being able to remember the organization in one look is well worth it.

u/underbeneath · 1 pointr/AskComputerScience
u/reddilada · 1 pointr/learnprogramming

&gt; it's hard to change things later

Can you identify why it's hard to change? Stop doing those things. Reflecting on what is the root cause of a problem is essential to improving one's self. When you have trouble always look back and ask yourself, how could I have avoided this problem in the first place?

There are a lot of practices that can help. Be organized. Be consistent.

A nice old list of guidelines to follow
Writing Solid Code
The Practice of Programming
The Pragmatic Programmer
Clean Code

u/redaemon · 1 pointr/leagueoflegends

I enjoyed this book for pointing out ways to improve coding style:

The book was recommended to me by a senior dev, and while I don’t agree with all the assertions in this book, I do think my code has gotten a lot more readable.

u/jimbol · 1 pointr/javascript

I try not to use square brackets when I'm not doing a variable lookup.
With $_GET['distro'] the string 'distro' never changes. So you can just use dot notation.$_GET.distro and cut out some characters.

Also if you're going to run a look up more than one, consider storing the results in a variable. For example you do distro[$_GET['distro']] a couple times. Instead store the result var distroValue = distro[params.distro]

This is especially important with jquery lookups like this $('#inner') because its a really heavy operation to execute a DOM lookup. Instead store the results of the lookup for later use. var $inner = $('#inner');

Heres an annotated version of your code with my notes.

Heres a more readable version of you code.

Also read Clean Code.

u/LaVidaEsUnaBarca · 1 pointr/ProgrammerHumor

This can solve your problems.

u/Opia · 1 pointr/learnprogramming

I have an e-reader (an old nexus 7 i got for £50 off ebay) and use the kindle app and the pocket app to read technical books/articles on the way to &amp; from school/work.

I don't read step by step tutorials so there isn't a need to do work after reading each paragraph, but rather books on good code practices (clean Code), and introduction guides to frameworks/tools (e.g. jasmine testing framework). I usually apply the knowledge into practice later that day or week when i'm actually coding.

u/ducdetronquito · 1 pointr/Python

I think you are good to go !

Last advice: even if you are not primarily a developer, try to read how to code well. For example, this book is gold: Clean Code: A Handbook of Agile Software Craftsmanship)

u/maxmoo · 1 pointr/datascience

Before OP worries about data engineering libraries, I'd be looking to see some more fundamental software engineering skills, i.e. things you might find in like

  • variable names
  • formatting
  • functions(!)
  • tests

u/haven1433 · 1 pointr/csharp

Regarding a decent README, I absolutely agree. My thought was that I would add one as soon as I have some of the basic features working. But I suppose that at the minimum I should add some sort of vision statement to a README so that you kind people at least can see my goal for the project.

Regarding comments: I actually agree with Clean Code, that using comments is usually a smell showing that the code isn't clear enough. Were there specific places where the code was hard to read, which made you want comments? Maybe there's some refactoring I could do to make the code more clear.

u/andoril · 1 pointr/AskProgramming

As stated by u/humpier I would recommend to look at other people's projects on Github and how they do it plus looking at popular frameworks in your preferred language and what their standards are.

As you mentioned Wordpress it seems you're more into web development, so maybe you could start with Laravel or Symfony and try to understand their standards.

And I don't know if this may help you and for me it changed how I think about organizing my code but you could take a look at Clean Code by Robert C. Martin. After reading it some things just fell into place for me, which had a lot to do with naming conventions.

u/Senipah · 1 pointr/vba

Most language style guides are broadly similar so there are generally accepted standards for how and when to indent code. Generally speaking indentation is used to denote control flow blocks. Each nested block is indented.

So for example you would indent any time you have one of the following:

  • For...Next
  • If...Else...End If
  • While...Wend
  • With...End With
  • Select Case...Case...End Select
  • Function...End Function
  • Sub...End Sub

    There is a VB6 style guide available.

    &gt;Because many programmers still use VGA displays, screen space should be conserved as much as possible while still allowing code formatting to reflect logic structure and nesting.

    &gt;Standard, tab-based, nested blocks should be indented four spaces (the default).

    &gt;The functional overview comment of a procedure should be indented one space. The highest level statements that follow the overview comment should be indented one tab, with each nested block indented an additional tab.

    If you look at the style guides for most other languages they will generally give the same advice.

    In certain languages, such as Python, it is particularly important to be familiar with this as correct indentation is used by the interpreter to run the code correctly (for example, there is no End If or End Function, the interpreter knows when the control block has ended by the change in indentation).

    It may seem like a pedantic thing for me to have even brought up (and it may well have been) but when you are used to reading code to certain conventions it makes it significantly easier to parse a function at a glance.

    Many would argue that vertical whitespace should be restricted to separating only blocks of related code but others (myself included) would argue further still that this should be a redundant argument as your code should follow the Single Responsibility Principle and thus if your function/method is doing more than one thing it should be broken down into constiuent function/methods anyway.

    I highly recommend Code Complete and Clean Code
    for a more in-depth dissection of these principles.
u/Lizard · 1 pointr/mentors

Diese Themen werden in jedem Informatikstudiengang behandelt, je nach Prof und Ausrichtung der Uni mal besser und mal schlechter. Wenn du solange Selbststudium betreiben möchtest, schau dir mal Code Complete sowie Clean Code an, die bringen dir vermutlich aktuell am meisten.

u/autisticpig · 1 pointr/Python

If you were serious about wanting some deep as-you-go knowledge of software development but from a Pythonic point of view, you cannot go wrong with following a setup such as this:

  • learning python by mark lutz
  • programming python by mark lutz
  • fluent python by luciano ramalho

    Mark Lutz writes books about how and why Python does what it does. He goes into amazing detail about the nuts and bolts all while teaching you how to leverage all of this. It is not light reading and most of the complaints you will find about his books are valid if what you are after is not an intimate understanding of the language.

    Fluent Python is just a great read and will teach you some wonderful things. It is also a great follow-up once you have finally made it through Lutz's attempt at out-doing Ayn Rand :P

    My recommendation is to find some mini projecting sites that focus on what you are reading about in the books above.

  • coding bat is a great place to work out the basics and play with small problems that increase in difficulty
  • code eval is setup in challenges starting with the classic fizzbuzz.
  • codewars single problems to solve that start basic and increase in difficulty. there is a fun community here and you have to pass a simple series of questions to sign up (knowledge baseline)
  • new coder walkthroughs on building some fun stuff that has a very gentle and friendly learning curve. some real-world projects are tackled.

    Of course this does not answer your question about generic books. But you are in /r/Python and I figured I would offer up a very rough but very rewarding learning approach if Python is something you enjoy working with.

    Here are three more worth adding to your ever-increasing library :)

  • the pragmatic programmer
  • design patterns
  • clean code

u/tannerz28 · 1 pointr/codereview

I'll chime in since I'm writing a large-scale bot myself.

First of all, nice job so far. You are making good progress. I've checked on your repo occasionally within the last day, and see that you are continually making improvements. Keep it up!

My suggestion pertains to code style/readability.

  • Don't abbreviate your variable names if you can avoid it. For example, in your `random.js` file, you have this line:

    r = Math.random();<br />
    ```<br />
    <br />
    On other lines, it would be ambiguous as to what `r` represents. I'd recommend to always use descriptive identifiers, because it makes your code more readable and maintainable.<br />
    <br />
    An easy fix for this would be to rename the variable to `randomNumber`. It only takes a second to type, but greatly reduces the amount of time it takes to understand your code.<br />
    <br />
    Another example is in `move.js` where you have these two lines:<br />
    <br />
    ```js<br />
    h = false; // no text setting<br />
    g = false; // no move<br />
    ```<br />
    <br />
    In theory, code should be &quot;self-documenting&quot;, meaning you shouldn't *need* a comment to describe what a variable is. In this case, you added comments to basically describe the variable.<br />
    <br />
    To resolve this, just change the variable to be the description of the variable, essentially, like:<br />
    <br />
    ```js<br />
    hasTextSetting = false<br />
    hasMove = false<br />
    ```<br />
    <br />
    With a descriptive variable name (identifiers in general), there is no need to add a comment to describe what the variable does, because the identifier should tell you what it does or holds.<br />
    <br />
    <br />
    If you want to gain a lot of good coding habits, I would highly recommend reading [Clean Code](<br />
    <br />
    <br />
    Otherwise, it looks good so far. If you have any questions about making a bot or need help, feel free to ask me. Contact me on Discord, Joker#3650<br />
u/t1ngel · 1 pointr/androiddev

Read this if you havent already. Helped me a lot ;)

u/fernly · 1 pointr/learnpython

Reading the TOC, I see a lot of good ideas and advice that resonate with my experience.

u/SpoobyPls · 1 pointr/learnprogramming

There are a few books I recommend. I think a couple of things are very important to wrap your head around, but before all that comes the basics. For instance, knowing your primitive types, methods, loops, and even OOP which would include things like; classes, structs, inheritance, polymorphism, etc,.

Then move onto some very good readings;

  1. Clean Code - This book is going to go through a lot of concepts and keeping your code maintainable and is a very short read.
  2. The Pragmatic Programmer - This one will go through, what I believe, you're looking for. Helps you get into the mindset of a 'pragmatic programmer.'
  3. Introduction to Algorithms - This I wouldn't start until you're fairly comfortable with programming in the language you are familiar with. By this point you should definitely have the basics down. In fact, I might argue do this one after you've read the other two.
  4. Lastly, I'd recommend doing Project Euler which is really going to put your skills to the test. It is very mathematical but if you're up for the challenge this will push you far.
u/NowImAllSet · 1 pointr/softwaredevelopment

Disclaimer: I'm an undergraduate and don't know shit.

I think the best way to learn is from the small parts, up. So, first learn a structured (preferably OO) programming language. Python will do, but I'd recommend something with compilation and static typing. Python is great for scripting and has its purpose, but designing and implementing a complex system in Python is a nightmare. After learning that, learn how to write your classes, methods and just generally structure your code better. I highly recommend Clean Code for that. After understanding good class design and code structure, start learning about higher-level concepts on how those well-defined classes should communicate with each other and be decoupled. Important concepts to learn are coupling and cohesion, polymorphism, inheritance, etc. All the basic OOP concepts. From there, you can move onto architecture. The book I used in my courses was System Analysis and Design, but there could very well be better ones out there.

Edit: Oh, and it's helpful to at least be knowledgeable of common design patterns. I really like SourceMaking's approach and explanations, but once again there's tons of good resources out there.

u/Teimoso · 1 pointr/OSUOnlineCS

[For coding best practices : ] (
Maybe you don't need to follow this to the T but it's helpful overall.

[For when you are stuck / architecting your program: ] (

Explain your code/talk through exactly what you are doing to a rubber duck or willing participant. A lot of times saying it out loud and explaining your code will help you find any holes to think about/fix.

u/austincrft · 1 pointr/MechanicalKeyboards

That's probably a good way to organize it then.

Here are a few good books to check out, if you care:

u/simonced · 1 pointr/ProgrammerHumor

I know right?! I was like that as well, until I had been enlightened.

Here is my new bible:

u/dzhv · 1 pointr/webdev

If you are a person who tries his best to keep his code tidy and readable, I strongly recommend reading this book:

If I recall correctly, their suggestion is to keep functions as short as a few lines and focus mostly on how you name them. But the general guideline is the same as most of the comments here mention: a function must do a single thing. Similarly to single responsibility principle of a class/module:

The book is really well written and has helped me a lot in making my code readable (atleast i hope so :) ).

u/KieranDevvs · 1 pointr/ProgrammerHumor

No one would ever do that though...

Have you not read Clean code?

A function that needs two lines to declare it is a bad function.
Encapsulate and follow single responsibility.

Any other examples where you need to mix them? Lets not waste time of you posting one example then I show you why its incorrect. Just list me all the instances you believe that you cant use tabs, and ill just correct them all in one post.

u/LessCodeMoreLife · 1 pointr/programming

You need this.

Among other things, there is a whole chapter on naming. It's fucking awesome.

u/konradzikusek · 1 pointr/programming

You can find same opition in ``Clean Code: A handbook of Agile Software Craftsmanship''. Code should be self-explanatory.

u/obliviouspenguin · 1 pointr/cscareerquestions

That sounds pretty normal especially for a small-ish company. A lot of learning comes from reading on your own. Like blog posts, StackOverflow etc. I really recommend Clean Code in terms of the stuff you're talking about. This book is basically a software engineering best practices bible.

Unit testing is something your team should help you with though. If a system is not there, you can also try to do some research and propose a system for your company to use or implement!

&gt; For me, I wish I had more mentoring so I can pick up new skills.

It sounds like you're learning a lot though. You built something that works using a new tech you learned from scratch. That's pretty impressive. It's a pretty unique opportunity to try new things and get paid.

u/spaghetti_slinger · 1 pointr/cscareerquestions


The Pragmatic Programmer ($30)

Clean Code ($40)

Structure and Interpretation of Computer Programs ($40)

T Shirts ($20-30):

Works on my machine

Hello world


A nice coffee mug or teapot for the office

Nerdy desk top calendar

u/maze-le · 1 pointr/softwaredevelopment

Try to make a sketch: What are the dependencies of each function / class / module. How are they interconnected, what is the scope of each dependency (can they be bundled into a module / class on its own?). I usually make such sketches on paper -- old school.

If you have the sketch, you can start unbundling it by trying to minimize the dependencies of each part to one another. Once that is done, you can either refactor or outright reimplement the code. Depending on how big the mess is, a complete reimplementation can be simpler sometimes (albeit more time consuming).

There are also very good books on that issue:

u/rdmeneze · 1 pointr/cpp_questions

I recommend you to read the book Clean Code ( There are a lot of tips on writing code that can be read by other people, like you eight months in the future.

u/writerofthecodes · 1 pointr/csharp

A great book that many companies require new hires to read:

Clean Code: A Handbook of Agile Software Craftsmanship

u/proginprocess · 1 pointr/learnprogramming

Currently Reading:
JavaScript - Professional Javascript for Web Developers

Software Design - Clean Code

Later on, I'll be reading this for Data Structures and Algorithms:
Introduction to Algorithms

Don't know what I'll do for a specific language later on. Probably go back to C# and see what I can churn out there.

u/alfred-nsh · 1 pointr/webdev

With the assumption you already have a good portofilo and linkedin profile, you can also try contributing to open source projects and have your own projects on Github. This might get you noticed. Open source projects always have this beginner bugs that needs to be fixed because the core members usually work on more important stuff. You can also try fixing issues for money with bountysource. There's also Stackoverflow, you can answer some questions there. Try to have a project of your own and if you learn new stuff you can write them up in a blog or something. These stuff not only make you noticed but also make you a better programmer as you will learn new stuff and practice your skills.

Also try to make yourself better. Everyday try to learn something new. Find about new frameworks and libraries. Read books and blogs. Also read this book if you haven't already: Clean Code. If you want to work with others, it's very important to write readable code.

And trust me, web devs can make a lot of money, so don't lose yourself. If you have any passion for what you are doing, don't ever give up.

u/Sheep_Goes_Baa · 1 pointr/roblox

What..... I'm gonna post the quote again. "Programs must be written for people to read, and only incidentally for machines to execute."

It's the same reason why you don't name all your variables "i" or "b" or "n". It's also why you don't write gigantic 300+ line functions, or why you don't put the actual value of a constant you're using instead of using a variable to represent it. Readability is everything. Who gives a shit if the operation is slower by 1 microsecond? If you're optimizing, there are way more options than to make you're code dirty. This is a good book to read on writing clean code.

P.S. You're using an integer but that method takes an Enum as the argument. So... your integer is just as "inefficient" as that string.

Edit: also, video:

u/phragg · 1 pointr/webdev

I highly encourage you to read Clean Code - Robert C. Martin. It goes over various naming conventions that many developers should adhere to.

Some of the most important topics covered is:

  • If you need comments, your code is not clear
  • When you're working with a team, come together to an understanding of how classes, functions, methods, objects, etc are all named and be CONSISTENT

    Here is a great coding standard that many developers use:
    Coding Style Guidelines
u/ignu · 1 pointr/programming


the mind can only hold several things at once. not 40. not 100.

that dailywtf example was someone failing horribly at not using comments. he was right in theory, just failed at execution. comments are a code smell. if you feel like putting a comment in a method, it is usually better to refactor to method and name your thing the comment you were going to write.

if you have to name it a run on sentence, then you're either failing at abstracting or your method is doing too much.

this is better:

function process_media_list(){


function process_media_list(){

further reading:


Clean Code

Why Comments are Evil

u/crowbahr · 1 pointr/programming

In broad strokes it's a goal tracking app with community interaction.

When it comes to design there are a few important pieces that you want to disconnect from each other for various reasons. Any app will have a view, a controller and a model, or some variation there on (there are half a dozen major schools of thought on this and dozens of sub-schools bickering violently about them but in essence that's always true). Usually you'll have 1 controller for each view which handles all of the interactions with the view. The really interesting part starts coming in when you get down to the model level where you're creating abstract representations of all of your data and doing manipulations on that data. Some people argue that manipulation should primarily happen in controllers, some in models. I personally have model controllers that use facades and interfaces to be accessed by and to access the other controllers and model(s). In those model controllers I do any manipulations and essentially leave the models as pure(ish) data structures which hold representations of what's going on.

Now I haven't really started designing the app because we haven't officially been brought on as a team to do the app (no money down = no work yet) but I can tell you that I have basic ideas on how I'll divvy up the model into manageable segments that can stand even crappy outsourcing. Let's take the goal portion of this software. Each goal will need to have a name, it'll need to have a list of users which are all competing on this goal and it'll need to have the metric they're competing for. It'll have to have % completion for each of the users on the goal saved somewhere and it'll need to be fetched from the server whenever someone loads up their app so that the most up-to-date version of everyone's progress is displayed. There will also need to be server side pushing happening to let players know when there is completion on a goal (Friend A finished 100 push ups goal today!). So that piece of the model needs some server connections. Well I need to establish an interface then for the server so that I'm not calling methods that might be renamed or changed entirely all over my code. The interface becomes a contract to always do things a certain way. So I create a [server fetchUpdatedGoals] call that happens when my app loads and the object which inherits from the ServerInterface class (ServerProxy in this case) will then ask the server for the data. Having collected that data the server proxy will then need to set it in the model. This can be done a couple of ways, either with call backs/observers or with hard coded access changes. If we went the hard coded access changes route I would package up all of the goal data (for many different goals) and send it to a facade between the server class and the main data model. In that facade I would unpackage the data sent by the proxy into the individual goals then set them within the model. The use of a facade means that even if the method signatures within the model change I don't have to change code all throughout the program, it blocks that ripple effect and keeps it localized in the facade. So if I change it from [model setGoal:int toGoalObject:GoalObject] to [model updateGoalObject:GoalObject] I would only have to make changes in the facade to change from the previous signature to the new signature.

That's one tiny piece of a much larger puzzle where your entire goal is to break things down into as small of pieces as you can and then separate them from each other as much as possible so that they're not interdependent on implementation but rather only on interfaces and facades. The design before you write philosophy means that you are less likely to have to make changes after the code is written and any changes you do have to make will be limited in scope. It also generally allows for easier unit testing as you have more modular systems that can run separately from others using dependency injection to create false analogues to deliver canned data for testing purposes.

If you're seriously thinking of switching over to software design I cannot recommend this book enough: Clean Code by Robert Martin. It talks about how to design code that is maintainable and simple. And my descriptions here might have rambled a bit (especially compared to how well he describes things) but I only blame that on me being sick with a bit of a fever. I'd love to answer any questions though.

u/Elynole · 1 pointr/nfl

I'll throw out some of my favorite books from my book shelf when it comes to Computer Science, User Experience, and Mathematics - all will be essential as you begin your journey into app development:

Universal Principles of Design

Dieter Rams: As Little Design as Possible

Rework by 37signals

Clean Code

The Art of Programming

The Mythical Man-Month

The Pragmatic Programmer

Design Patterns - "Gang of Four"

Programming Language Pragmatics

Compilers - "The Dragon Book"

The Language of Mathematics

A Mathematician's Lament

The Joy of x

Mathematics: Its Content, Methods, and Meaning

Introduction to Algorithms (MIT)

If time isn't a factor, and you're not needing to steamroll into this to make money, then I'd highly encourage you to start by using a lower-level programming language like C first - or, start from the database side of things and begin learning SQL and playing around with database development.

I feel like truly understanding data structures from the lowest level is one of the most important things you can do as a budding developer.

u/SuperDuckQ · 1 pointr/learnprogramming

There are two books I would recommend to you as I think they address what you are looking to improve upon. First I would recommend

Clean Code: A Handbook of Agile Software Craftmanship

followed up by Code Complete

Both deal with project management, etc., but have fantastic sections on code style and presentation. I really liked "Clean Code" and would recommend it to anyone. What you are describing in your last paragraph is one of its main goals. Both books present principles that are language agnostic (though usually have examples in Java/C formatted languages).

u/interactionjackson · 1 pointr/learnprogramming

I would never say never. They have their uses but there is definitely some best practices to adhere to if you choose to use them. Clean code by Robert Martin is a great book to read and details best practices.

u/frostbite7217 · 1 pointr/Android

Check out r/androiddev, the commonsware guides, and the official android docs. To be honest, unless you have good CS schooling, coming from light web development, you should really take a look at proper development practices and get an understanding of Java before attempting development. This will help with one of the major problems on the market place, bad, poor performing apps. I'd recommend one of the O'Reilly Java fundamentals and Java best practices book, a good book on design patterns, and a refining book like Clean Code .

u/zerokilly · 1 pointr/learnprogramming

Clean Code is for you!

u/qualiaqq · 1 pointr/utdallas

I frequent r/cscareerquestions and if one piece of advice gets reiterated more than any other, it is the importance of programming as a hobby.

I took programming fundamentals I and II at TCCD before I decided to transfer here, and I was surprised to find out that fundamentals II is equivalent to compsci I not II. In addition, programming fund I (a 4 credit hour class) is equivalent to the developmental programming class offered here that people test out of in like 15 easy multiple-choice questions. I'm hoping CS2 at UTD is much better than what I already took. I hope you didn't fall into the same trap I did.

&gt;would not programming in my free time also be damaging to my undergraduate journey towards a CS major/job?

I personally think if software development is your goal, then not programming at all is going to limit your opportunities when you graduate. I think ideally you want to get an internship and get paid to program. Doing it on the side can help you get that internship. Also, If you care about programming, then it makes it easier to read about it. A good book I can't recommend enough is clean code and/or the video series of the book.

I mean its just like anything else in life. I can play the first few bars of the song "One" by Metallica on the guitar, but I can't play the whole song. Why? because I never put in the effort it takes to get good at playing the guitar, so I suck at it. Software development is no different.

u/danimoth2 · 1 pointr/ruby

I think you have to read a lot of different books to get things, but for me, Destroy All Software is really good. You have to pay for it but you'll get your money's worth in terms of productivity gains. Clean Code had a big effect on my code after. Check out Uncle Bob's talk here. Google all of Sandi Metz's talks but this one is my favorite. She also wrote Practical Object Oriented Design in Ruby, awesome. You still have to code though! I think you'll figure out patterns just by coding and asking around.

u/MerlinTheFail · 1 pointr/gamedev

This is really cool! Thank you.

&gt;A common question is whether the book is still relevant. After all it's over ten years old

I find that some old(ish) books can really hold some great significance, for example: Effective C++ and Clean code have both given me some brilliant tips on making better code. I'm also readingWrite Great Code. If you have any more books i'd love to see them :) Thank you, again.

u/onetwosex · 1 pointr/datascience

OP, so that you know, you mention uncle Bob's "Clean Code", but your link redirects to the book "Clean Coder". They're both great, but different.

I've ordered the book Practical Statistics for Data Scientists: 50 Essential Concepts. Looks great to brush up the basics of statistics and machine learning. Since I haven't actually read it yet, take my input with a grain of salt.

u/aztristian · 1 pointr/androiddev

That is a very broad question. To be a good programmer you have to practice (program) a lot and not just the same thing, but various kind of projects and challenges, there are just too many areas to list here and the challenges vary by programming language, operating system to the actual problem domain.

Choose a language or 2 from different paradigms (functional, OOP, structured) and try to solve the same problem in each of them.

You'll also want to spend time doing some reading, some well known books for example:

  • The Pragmatic Programmer
  • Clean Code
  • The Passionate Programmer

    For just the programming aspect you can start trying to solve leet code style questions such as the ones found in Coder Wars or Leet Code

    The following book does a much better job at providing an overview of what you can do as a programmer and the available career paths:

  • The Complete Software Developers Career Guide

    &gt; And second question backend or mobile development(native) in future?

    For this I think you can be a successful professional in either, there are times when you can get away with not needing a "backend" with custom logic and you can just use a data store, but if you ever need to do some centralized processing or computation that requires more resources (memory, CPU) than a typical device can offer there's no escaping the need for backend development. The challenges in the backend are very different to the ones on the frontend (be it native or web based) and the approach is more focused on system design with a bit more traditional Computer Science topics.
u/Ran4 · 1 pointr/learnpython
  1. Read pep8 - the official python styleguide and format your code according to it. You can run the flake8 tool on your code to get an error report.
  2. Read the book Clean Code by Robert Cecil Martin. It's a classic, and offers tons of great advise.
u/grep65535 · 1 pointr/csharp

For programming and everything involved with it, if you want standards and "how should I do this?" questions answered for you, reference this:

Clean Code: A Handbook of Agile Software Craftsmanship

Get yourself a copy, read it twice, then you can show your senior what the standard is.

u/chrome_x · 1 pointr/compsci

First, I don't read books too often. So when I do read, I try to find books that have some form of practical aspect in it. I am currently reading Clean Code ( and it has exercises to help me understand the situation and to show me how I could design software in a better way. Not only does this help me understand the problem better, but writing/executing the code and feeling the problem makes me really understand why the particular solution is the best solution.

I do not usually take notes because i won't read them again(sorry I know myself too well). I prefer doing these exercises once in a while and hoping that I would be able to fall back on my intuition when I encounter something similar at my job/class/internship/personal coding time etc.

u/sleepybychoice · 1 pointr/learnprogramming

Googleable terms might be "software design" and "software architecture".

A good way to learn about why certain designs work and some don't (work well) is to read case studies of software engineering failures and what design decisions contributed to various problems. Searchable terms for this would be "case study", "retrospective", and "postmortem".

I'd also suggest Clean Code by Uncle Bob.

u/AMY_bot · 1 pointr/learnprogramming

For less messy amazon links you can extract the part after "/dp/" in;amp;qid=1484198506&amp;amp;sr=8-1&amp;amp;keywords=clean+code

and make it:


Plz send any recommendations via PM

u/Venthe · 1 pointr/csharp

If possible, avoid it. C# already provides you with enough clarity

public Variable {get;set;}
private variable;

public SampleMethod(variable){

Also, descriptive variables are beautiful. Take look at the Clean Code if you haven't had an occasion.

Of course underscore notation is used (sometimes) as could be seen here:

u/eru_melkor · 1 pointr/learnprogramming

Some general advice:

Read this book: clean code. Also, go through oracle's coding standards. The company you will work at might have their own coding standards but they are all pretty much based on oracle's. So try to follow that.

Critics on your code:

  • if you follow oracle's conventions, then your class variables shouldn't start with an underscore. I mean, it is a legal variable naming system, but this is not the convention.

  • The following comment is completely unnecessary. Use comments to describe why you are doing certain things. Don't explain the code. Explain why is it the way it is (if necessary).

    /* If no connections, remove connected CSS class */

    if (this._model.getConnections().size() &amp;lt;= 0) {

    getStyleClass().removeIf(element -&amp;gt; element == &quot;connector_connected&quot;);


  • The following comment should be a doc comment. The comments above a method should be a doc comment

    /* Set GUI behaviour that cannot be defined in CSS. */

    private void setDisplay() {


  • THe comments before a class variable should also be a doc comment. This is because when you generate java docs (html documentation), the program that creates the docs will read your source code and look for doc comments

    /* Holds connection data for managing non-GUI behaviour. */

    private ConnectorModel _model;

    edit: formatting
u/WhenDatWeedIsGone · 1 pointr/IAmA

Is it this one I should buy?

u/TheCluelessDeveloper · 1 pointr/ProgrammerHumor

Eh... documentation should be an overview of the process. Specifics need to be within the code itself. Self-commenting code + coding standards is a real thing.

I would recommend any developer to pick up Clean Code and learn some of the basics on self-commenting code and how to write easy-to-read code.

u/TheCellch · 1 pointr/learnprogramming

we worked through some items from Effective Java and Clean Code but that is more of an addition and good to know. The Principles we learned were just worked into the lessons and nothing from books. Here's the list of them so you can take a look at them, Wikipedia should give you more information (I linked them for you). However it is important to not just read them and add a checkmark, some of them really change the way you programm. You can't respect all of them cause some will exlude others. And finally not all are really principles some are more of a guideline.
Start with SOLID:

  1. (SRP) single responsibility principle
  2. (OC-Principle) Open/Close Principle
  3. (LSP) Liskov substitution principle
  4. (ISP) Interface segregation principle
  5. dependency inversion principle
  6. (DRY) don't repeat yourself
  7. (CoI) Composition over inheritance
  8. Effective Java Item 17 Design and document for inheritance or else prohibit it
  9. Loose coupling
  10. Test-driven development
    no real Principles from here on:
  11. differ Information Hiding from encapsulation
  12. Use speaking names for classes, methods and attributes
  13. A lot of little units is better then one big (refering to classes)
  14. Use Interfaces to abstract and decouple

    I just checked my notes and here is what I did not mention so far:
    We of course learned the Encapsulation (public, private, protected none). We learned about Collections ((Java Collection Framework) Map, Set, List and the different implementations). Threading, concurrency, Executor, Queue and Dequeue, MVC, Event/Listener Pattern, Exceptionhandling, Comperator, Hash and Equals, Polymorphism, casting.

    Please not that we are not professionals on all this we just learned the basics more or less.

    Hope this helps
u/i_do_floss · 1 pointr/funny

The practice of TDD works best for compiled langauges. But even for compiled languages, the experts on the topic disagree on whether test-first is necessary, or if test-later is ok. I've found that test-later works best for me, just make sure you're writing unit tests before you're testing your code through the UI. Generally I build small classes (150 - 250 lines each), then write all the unit tests for the class after I wrote all the code for the class.

You shouldn't write tests for every function. Your tests should exercise every line of code, and every business rule, but the interface that your tests use against your classes should be the same interface that the rest of your code uses against your classes. Writing tests for every function means that you would need to re-write the tests whenever you refactor, which will cause you to move slower.

I would suggest reading this blog post

It shouldn't be difficult to write unit tests against your code. If you are finding it really confusing and difficult, it may be because your function size is too large, or your design is too complicated. Breaking your design into smaller classes, and smaller functions will make it easier to test your code, but ultimately simplifying the design is where most time and effort is saved. You know the design is good when it's very clear how to easily test it. I've found this book to be a good resource in general.

If you're trying to add tests to existing code which has 0 tests, and wasn't designed for tests, I would expect that to take a long time. There's no way around that. Often I find it better to refactor that code, because it's not usually designed well either.

You save time writing unit tests, because it means that you can spend less time testing through the UI. You can test all your business rules using unit tests. When you test through the UI, you're only checking that everything is connected together properly.

The company I work for is similar to the one you described. When I started here, I went against the grain and built things slowly and carefully. My boss recognized the quality of the work I build and now chooses to put me on critical projects, with the expectation that I will spend 2-3x as long as other developers, but also with the expectation that what I build will work well. I've found that this has caused an improvement in quality of life for me, because I'm not in a rush all the time. The reason it takes me longer than other developers is not because of the unit tests though, it's because I refactor code all the time.

u/alexcp · 0 pointsr/learnprogramming

A book that I would highly recommend is Clean Code by Robert C. Martin, it will teach all the good practices programmers need to know.

The book teaches rules that can be apply to every languages.

u/bhldev · 0 pointsr/learnprogramming

If you read and follow "Clean Code" or follow Agile/Extreme programming you will basically create a new method every time there's a function or subroutine exceeding five lines.

Using that style of programming, each method would have one and only one purpose. Nested loops would deserve a new subroutine or function. In fact any control structure at all would deserve a new subroutine or function. The amount of documentation that goes around the function and the exception handling would easily exceed the size of the loop itself. The code itself would be one to three lines per function/subroutine.

This gives old school C++ programmers, sysadmins and generally everyone else who isn't using Agile a headache and creates issues with certain languages. But it is certainly the right way to develop maintainable clean code with Java or Java-like languages. You will see it in the wild only in the most up-to-date, modern shops that care about maintainability. Most shops will have dirty code with functions and subroutines dozens or hundreds of lines long.

u/aleczapka · 0 pointsr/PHP
u/patroniton · 0 pointsr/DotA2

No. I write my code so that you understand what's going on without having to read comments.

I suggest reading this book and taking a note on the comments section where he explains that comments can be more harmful than helpful.

u/snaftyroot · 0 pointsr/webdev

if you put such an emphasis on commenting your code, you would benefit from reading Clean Code:

code should have little-to-no comments (differentiating between comments and API documentation). the more comments you have, the more difficult your code is to maintain. instead, choose descriptive variable and function/method names and separate non-obvious logic into methods and functions. by inverting control, your top-level logic should read like a book

that being said, you're right about working with others. that's much more important than anything else

u/uzomi · 0 pointsr/gamedev

Well, when talking about code maintainability it's not the same thing.

It's clear that both of you do not understand the concept of clean code. That's why you guys think that there is some language barrier that does not exist since you guys do not know what concept I'm talking about.

There is some stuff that's very valuable for every programmer to read and I recommend for you guys.

Clean Code

Working Effectively with Legacy Code

The SOLID principles

Those are very good books, give it a try and you might thank me later.

Have a nice day to you too Inukai!

u/tzar1995 · 0 pointsr/datascience

Comment your code is one of the worst advices out there... I recommend you and the OP read this book before giving advices on what to do: CleanCode


PD: I agree with the other two points

u/Toe-Bee · 0 pointsr/ProgrammerHumor

Ok, I was just giving my opinion. If you want to be a better developer read about it:

It’s simply the idea of writing a test for the desired behaviour before writing the code (let the tests ‘drive’ the development).

For reading on how to write clean code: it has a whole chapter on TDD

u/Xen0m0rph · 0 pointsr/Romania

.NET, cool.

Nu subestima niciodata importanta dezvoltarii cunostintelor tehnice. Sunt considerabil mai importante decat acele "soft/social skills" in domeniul asta, mai ales daca vrei sa ajungi departe in directia asta (senior dev, arhitect, CTO etc.). Cu astea incepi intai - daca vrei sa treci spre management in schimb (care deviaza deja de la software design &amp; development cu mult, e practic alta meserie si s-ar putea sa nu-ti placa) atunci poti lucra puternic si la social skills.

Gandeste-te in urmatoarele 6-12 luni cam pe ce ti-ar placea cel mai mult sa te axezi: front-end, back-end, mobile, devops... In functie de alegerea asta stabileste-ti un subset de framework-uri (EF, Web API, MVC, etc.) pe care sa devii foarte versat, sa fii pe ele in cei top 25% (sau chiar 5%!) din compania ta, asa cum zici ca erai si in facultate. O sa dureze, dar merita efortul. Si nu-i lasa pe altii sa aleaga pentru tine pe cat posibil.

Si neaparat, citeste constant carti in domeniu. Nu te limita doar la blog-uri si articole pe net, alea nu mi se par ca sedimenteaza cunostintele asa cum o fac cartile. Citeste cat de des poti carti de inginerie software in general si .NET in particular. Cateva recomandari:

Pro C# 2010 and the .NET 4 Platform

CLR via C#

C# in Depth

Dependency Injection in .NET

Clean Code: A Handbook of Agile Software Craftsmanship

Astea sunt doar cateva, n-are rost sa mai extind lista, sigur vei gasi trimiteri catre alte carti de referinta citindu-le pe cele enumerate mai sus sau din discutii cu colegii.

u/nat_pryce · 0 pointsr/programming

I haven't seen this suggested, but it is a good book on exactly that topic.

Clean Code by Robert Martin.

and I have to mention...

Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Yours Truly, which frequently touches on that topic

u/garrypig · -1 pointsr/MachineLearning

I think this book recommendation might be appreciated on this thread:
Clean Code: A Handbook of Agile Software Craftsmanship

u/eggn00dles · -1 pointsr/cscareerquestions

ahh hyperbole. always refreshing.

i'm saying to comment your code through clean naming conventions.

have you ever read just code and instantly understood what it did? it's a pretty cool experience.;amp;qid=1559240556&amp;amp;s=gateway&amp;amp;sr=8-3

id rather strive for beautiful explanatory code than crap up the code with verbose and often unclear or misleading comments.

comments can be counter-productive.

u/wickermoon · -1 pointsr/programming

I'll just leave that here.
Don't know why people have to invent idiotic names for concepts that already existed several years ago...

u/joshuaherman · -2 pointsr/reactjs

If you read this book you wouldn't need that one.

u/stefan_kurcubic · -2 pointsr/learnprogramming

woah! brave young man right here!

how to be developer 101


  1. listen to your gut and trust it (it knows what it is saying and why)
    1.5 find a goal, set schedule and stick to it.
  2. stay healthy. eat regularly, sleep from 10-6, exercise 30min/day (walking is good), drink water
  3. this could be the best thing that happened to you. there is a reason for everything
    if you devote a year to this. you will be ready for a job and since you know stuff already it is going to take even less!!
  5. discipline!!!!!!!!!!!!!!!!!!! do it everyday think about how you can improve, find out about something new, implement new ideas, your calling is to be PROFESSIONAL webdeveloper ACT LIKE ONE.

  6. mindset -
  7. fit more easily in a team -
  8. BUILD BUILD BUILD BUILD BUILD BUILD. you learn by doing not by thinking or reading. put everything on github YOU ARE PROUD OF

    after you complete FCC

    or if you are hungry look here

    write me in a year
u/theedeacon · -6 pointsr/learnprogramming

Your code should hardly need any comments. Your code should speak for itself. Check out the book Clean Code.

Worth looking into. I understand you are talking about other people's code. Just pass this message along. it is worth to own a few to let fellow devs borrow!

u/Nalha_Saldana · -13 pointsr/ProgrammerHumor

If you have more than two levels of indentation you should break it into multiple methods. If you want to know more I would recommend reading clean code.

Edit: Before you downvote you should know that this isnt my idea, the Clean Code book is even more restrictive and is one of the most recommended books among programmers and companies out there.

u/masterchifchaf · -19 pointsr/pokemongo

On a side note, you should have a read of this book

It explains how you should layout your code, method and variable names so that you never need comments to explain what is happening! :)

For example, what does the var quantities mean? quantities of what? Possibly rename it to quantityOfPokemon?
A lot of your if statement conditions could be extracted to methods to make them a lot more readable, eg -
if(parseInt(candies/candiesToEvolve) === 0 || quantity === 0)
you could extract the conditions to separate methods/functions called isNumberOfCandiesEqualToZero so that your if statement would look like this:
if(isNumberOfCandiesEqualToZero || isQuantityEqualToZero)
This makes the code so much easier to read! Remember to code as if someone who has no clue about the code is looking over your shoulder. You don't want to have to explain that this thing parses the integer value, you just want to allow them to read the function name and they will immediately understand! :)