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

Here below is my copy pasta of C#/Unity stuff which I post pretty often on /r/learnprogramming and /r/learncsharp . I only need to find a moment one day and add some computer science theory links.

Free C# ebook

• http://www.csharpcourse.com/ <- The download link is under 'here' at the end of the first paragraph.

Youtube tutorials:

• https://www.youtube.com/playlist?list=PLGLfVvz_LVvRX6xK1oi0reKci6ignjdSa <- apart from C# this dude has also A LOT OF other tutorials on many other languages.

• https://www.youtube.com/watch?v=pSiIHe2uZ2w <- has also pretty good Unity tutorials.

• https://scottlilly.com/build-a-cwpf-rpg/ <- learn WPF (desktop application with GUI) by making simple RPG game.

• https://www.youtube.com/user/IAmTimCorey <- This guy is also good, but I dislike his coding style and that he uses a lot of nugets instead of writing stuff himself.

Book reference guide:

• https://www.amazon.com/C-7-0-Nutshell-Definitive-Reference/dp/1491987650/ref=sr_1_1?ie=UTF8&qid=1547990420&sr=8-1&keywords=C%23+in+a+nutshell <- But treat is as a language reference guide, not a programming learning guide.

Text-based tutorials

• https://www.tutorialspoint.com/csharp/index.htm <- C#

• https://www.tutorialspoint.com//wpf/index.htm <- WPF (GUI programming)

Udemy - wait for $10 sale which occurs at least once in a month:

• https://www.udemy.com/csharp-tutorial-for-beginners/ <- for C#, dude has also more advanced tutorials to choose from.

• https://www.udemy.com/user/bentristem/ <- for Unity

Do not move to Unity or WPF before you get good grasp on C# syntax and OOP concepts. Bear in mind that majority of Unity tutorials present abysmal C# coding style and practices. So I wouldn't recommend learning C# from such courses.

Coding style (read after getting good grasp of OOP concepts)

• https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship-ebook/dp/B001GSTOAM/ref=sr_1_1?keywords=clean+code&qid=1562330510&s=gateway&sr=8-1 <- Clean Code, recommended for every newcomer at my work

• https://www.amazon.com/gp/product/B075LRM681?pf_rd_p=2d1ab404-3b11-4c97-b3db-48081e145e35&pf_rd_r=22NFZ5GCWM7YMK2A5A2G <- Clean Architecture

Code: The Hidden Language of Computer Hardware and Software

Clean Code: A Handbook of Agile Software Craftsmanship

Code Complete: A Practical Handbook of Software Construction

Algorithms

Types and Programming Languages

Is it this?

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship-ebook/dp/B001GSTOAM

​

What I learned from reading Clean Code [1] is that developers spend far more time trying to read/understand code then they do actually writing it, they gave an empirical ratio of 10:1 for the time spent reading vs writing code. So I think it's worth it in the long run to make your code cleaner/understandable for other devs.

I highly recommend the book, they even have an entire chapter dedicated to meaningful names, so I think it's important to refactor variable names as well.


[1] Page 13 in the "We Are Authors" section (you can actually see it in the Amazon preview if you want)

Clean Code. I will always recommend it to any developer.

​

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship-ebook/dp/B001GSTOAM

It does the job, good stuff! I think you've got loads of suggestions about the actual code / arrays.

For me an important programming skill is called "clean code", there is a book.

It may be a little over the top given you are learning arrays, but I'll rabble on a little bit about it as I think its quite a simple premise and also I think a real good thing to start doing as soon as possible as it can keep clean and code simple.

Essentially how to make your code easier to read and understand. It applies to any coding, not just java. Short can curlies relating to your code post, meaningful naming and small methods that do basically 1 thing.

So for example take line 25:

if (userChoice > 12 || userChoice < 1) {

I dont know right away what that is doing or it means. Given we are talking about months, this looks like a range check and looking at the code within the if statement I can figure out it looks like this is the "good / valid" part of the check and we another have a bad / error check as well.

But the problem is I have to figure that by looking at what the code is doing. In another example where its not months / something new to me and the if's are doing something a little more clever, it'd be alot more difficult to figure what the code is doing.

So one / the traditional solution is to write a comment something like:

// bounds check the user input to make sure its a valid month
if (userChoice > 12 || userChoice < 1) {

But comments are likely to get old + out of date if someone makes changes and ignores the comment (happens all the time). They also muddy up the code with extra lines / make it harder to read + understand.

So an alternative way is extract the if logic to another method and give it a nice friendly name, for example:

if(isValidMonth(userChoice)) {
... rest of method...
}

private boolean isValidMonth(int input) {
return input > 0 && input< 13;
}


Now when you read you read that if statement its telling you exactly what its doing so you dont have to figure anything out yourself. Its quick, easy and clean. If this logic is difficult / doing something odd, then rather a comment, you can right some javadoc for the method.

See my example below of one way the main loop in your application could look:

while (continueInput) {
printUserMenuToConsole();
userChoice = userInput.nextInt();

if (isValidMonth(userChoice)) {
printSelectedMonthToConsole(userChoice);
String askQuit = getIt.nextLine();
continueInput = isContinueInputQuit(askQuit)
}
else {
printErrorMessage(userChoice);
}
}

You can see how that loop now is much more readable, its telling the reader what its doing. Essentially what is happening is taking a method that does a lot and break it down into smaller more manageable chunks and separating process and logic.

It still is a little clunky, we could take that one step further:

private void doUserInputLoop () {
boolean continueInput = true;
while (continueInput) {
printMonthMenuToConsole();
takeUserMonthAndPrintToConsole();
continueInput = doesUserWantToContinue();
}
}

You can see here the logic / complexity of all the months is now stripped out each into there own methods and this method is not much smaller and is all about the process of the loop. Within 2 seconds you can understand what you app does by reading those 3 lines, print menu console, get user input and print to console and ask use if they want to loop again. Its a little clunky with the while loop / boolean but its not too bad.

Its handy as well becuase if the code tells you what its doing, you never (or very rarely) need to write a comment.

Word of warning, balance is everything, this can be taken too far. The key is to name variables / method names fully to describe what they do (your variables are good). If you cant / struggling to come up with a name or they are getting too long, then its warning bells that a bit too much is going on / there is probably a simpler way to achieve what you are trying to do.

The answer to that is really a bunch of variables that you have to determine yourself. Answer these questions and others I havent thought of and then use them to calculate if its worth keeping:

How much longer am I going to use this code? is it temporary code? are other people using this code? Is coming back to this code in 6 months or a year going to be a nightmare? Am I going to be working with this code often? Is the sloppiness of this code causing other problems or might it in the future, and how serious are those problems? HOW MUCH TIME AND EFFORT WILL IT BE TO REWRITE THE CODE VERSUS ALL OF THE POTENTIAL TIME AND EFFORT THAT WILL BE ADD FROM UNFORSEEN PROBLEMS FROM THIS SLOPPY CODE?

-----
The capitalized part is the final question you can use to decide to rewriting it. Keep in mind its easy to underestimate future headaches from being sloppy.

-------------

Some random basic links on not writing sloppy code:

An EXCELLENT book on the subject:
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship-ebook/dp/B001GSTOAM

other links...

https://blog.alexdevero.com/6-simple-tips-writing-clean-code/

https://www.butterfly.com.au/blog/website-development/clean-high-quality-code-a-guide-on-how-to-become-a-better-programmer

https://www.pluralsight.com/blog/software-development/10-ways-to-write-cleaner-code

Clean Code can probably help somewhere.

Do you know any Software Design Patterns? They are more of what you are looking for I think. Design Patterns are a way to structure your code so that you don't repeat yourself, keeps code understandable since it follows guidelines from the pattern.

Head First Design Patterns is probably a good place to start with that, and once you understand the basics I would recommend you read the highly recommended Gang of Four (it's nicknamed because of the four authors).

You mentioned some issues that sound like code cleanliness and structural issues. Getting better at algorithms really comes down to practice and exposure, there's no shortcut to this. But there's no reason to suffer from bad coding practices if there's room to improve.

A few books come to mind, which may seem like they're coming from left field, and may not seem immediately useful to the task of solving algorithm puzzles, but might be useful in the long term for you to learn how to write correct, clean code and reduce uncertainty:

• Code Complete 2. Some good tips in here regarding code cohesion, and how to write functions and classes cleanly.
  
• Clean Code. More on writing functions cleanly, along with design & testing.
  
• How to Prove It. This is a great book that delves deeply into logic. Even just the first chapter or two could be incredibly useful to you. It discusses things like DeMorgan's Laws, which show up a lot in programming and electronics. It deconstructs common logical concepts and phrases into boolean algebra and set builder notation (which inspire Python's list comprehensions). The world of math and logic and proof is not completely isolated from the world of programming.
  
  EDIT: One other thing is to make sure you understand the limitations of how computers represent numbers. The need for this understanding will become clear very quickly on, say, Project Euler problems. Look into bits, values, integers, signed vs unsigned, IEEE754 floating point.
  
  And one other thing is that it's easy to compare your solutions against some of the best solutions that exist for those problems and think you're doing a bad job when in fact you're doing an alright job if you manage to solve the problems with decent runtimes. Mind your 80/20 rule here. The extra time it probably took those people to craft those solutions is not 0, which includes whatever time they spent over the years becoming an expert at that language, etc.

Your foes are kids in their twenties with a degree which takes years to achieve, this will be tough! But I think your age and your willingness to learn will help you lot.

​

Other things to learn:

• JDK - you should be at least aware what API's the JDK provides, better, have used them (https://docs.oracle.com/javase/8/docs/). I think (personal preference / experience) those are the minimum: JDBC, Serialization, Security, Date and Time, I/O, Networking, (Internationalization - I'm from a country with more than one official language), Math, Collections, Concurrency.
  
• DBMS: How to create databases and how to access them via JDBC. (I like postgreSQL). Learn SQL.
  
• Learn how to use an ORM Mapper. (I like jOOQ, I dislike JPA/hibernate)
  
• Requirements Engineering. I think without someone who has the requirements you can't really practice that, but theory should be present. It's a essential part of software development: Get the customers requirements and bring it to paper. Bad RE can lead to tears.
  
• Writing Unit Tests / TDD. Having working code means the work is 50% done - book recommendation: Growing Object-Oriented Software, Guided by Tests
  
• CI/CD (Continuous Integration / Delivery) - book recommendation: Continuous Delivery.
  
• Read Clean Code (mandatory!)
  
• Read Design Patterns (also mandatory!)
  
• (Read Patterns of Enterprise Application Architecture (bit outdated, I think it's probably a thing you should read later, but I still love it!))
  
• Get familiar with a build tool, such as maven or gradle.
  
  ​
  
  If there's one framework to look at, it would be spring: spring.io provides dozens of frameworks, for webservices, backends, websites, and so on, but mainly their core technology for dependency injection.
  
  ​
  
  (edit: other important things)

Possibly one or both of Bob Martin's books.
Agile Software Development, Principles, Patterns, and Practices (comes as a Java or C# version, but many of the ideas will probably be useful if you are using an OO language) or
Clean Code

Sure thing. It is called Clean Code: A Handbook of Agile Software Craftsmanship

The Pragmatic Programmer

Clean Code

Introduction to Algorithms

There is writing readable code, and there is good design & architecture. When you do both it's called writing clean code.

Writing unreadable code does not necessary trap you, it traps your teammates. Build your software with poor design and architecture will trap everyone. Just remember the main purpose of writing clean code is not for yourself, it's for your teammates.

E` sulla mia scrivania da alcuni anni, presenza fissa (rileggo pezzi ogni tanto).

Insieme a lui anche questi:

https://www.amazon.it/Clean-Code-Handbook-Software-Craftsmanship-ebook/dp/B001GSTOAM

https://www.amazon.it/Code-Complete-Developer-Best-Practices-ebook/dp/B00JDMPOSY/

e questo

https://www.amazon.it/Practice-Programming-Addison-Wesley-Professional-Computing-ebook/dp/B00HU50A12/

Non lo sto chiedendo strettamente per me, ma piuttosto per avere una conversazione sull'argomento (e magari per imparare qualche nuovo trucco).

Grazie comunque per aver citato uno dei libri che piu' apprezzo sull'argomento.

If you are only used to CodeIgniter, you probably lack a lot of OOP knowledge. Grab a copy of clean code and go through the clean code talks

I very highly recommend you checkout the book Clean Code by Robert Martin. It is a brutally honest critique of software development like you've described, and lays out lots of problems with doing it that way. And he is spot on almost every time. Then, he explains the correct way of doing things, even going through his refactoring process to get bad code to good code. He frames software development like writing an essay. You don't turn in your first draft, you do multiple iterations to make it good. He even admits his first draft is not clean code, it is him going with the flow to solve the problems. The difference, is he doesn't consider that "done" even though the tests all pass and the feature works. It isn't done until he goes through and refactors it, multiple times, until the code is clean, and concise. Code like that makes bugs hard to hide, and easy to fix.

Not much to go on. Let's try this.

Do you understand the notion of decomposition? A well-organized program will have many functions, each of which does one thing and does it well. The higher level functions will use these as a toolkit to orchestrate more complex tasks. A program organized in such a way is easier to continue adding to even as it grows large.

Let's have an example. You have made the following lower-order functions in a hypothetical game, each of which does exactly what they advertise:

advanceToNextTurn
setPlayerMaxHealth
setPlayerSpriteGraphics
playSoundEffect

These are simple functions. Now let's make a function that uses them as a toolkit to accomplish a larger task. Let's turn the player into a werewolf.

def changePlayerIntoWerewolf():
setPlayerMaxHealth(player.currentHealth * 1.2)
setPlayerSpriteGraphics("sprites/werewolf")
playSoundEffect("audio/werewolf/howl.flac")
if(player.movementPoints < 1.0):
advanceToNextTurn()

Let's make an even higher-order function that uses this one.

def advanceMoonPhase():
if(moon.phase == 0): # full moon
if not player.inWerewolfForm:
changePlayerIntoWerewolf()
else:
if player.inWerewolfForm:
changePlayerIntoHuman()

Regarding your Roguelike - it's pretty simple as it is. I'm not sure what kind of trouble you have with it. A few hundred lines of code in a few files is not a complex program. You might consider rethinking some of the parts in terms of more stringent modelling of the game elements (for instance, shouldn't you have a Map class with all of the map data and information about which Being is standing where? Your movement methods might take the current game Map as an argument).

Books are always nice. Reading code is important, and there are many good books with excellent examples.

• Pragmatic Programmer
  
• The Gang of Four book
  
• Clean Code

> 7

This is an anti-pattern. Even if you were going for hyper-performance code (which is a little silly in Java), the Compiler these days is typically very good at optimizing this type of code.

> 13

This guy hates functional programming. If you used a lambda, or Java streams, would you just automatically flunk the class?


From an overall perspective, I'd say this guy hasn't really learned much about computer science (if anything) in the last 10 years. If he intends to be an educator, code style should be based on a real style guide or well known book like:

• https://google.github.io/styleguide/javaguide.html
  
• https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship-ebook/dp/B001GSTOAM
  
  Of course that would require him to actually do some reading an learn something. God forbid a teacher learns something.

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship-ebook/dp/B001GSTOAM

Thanks for your feedback and for digging into the code! It was a big help. Also sorry for the late response.

> Only found one 'bug'

I will fix it.

> You also might want to rework your 'blocks' array

You are right, this will make it easier.
I wanted to make the enemies move around the map, maybe this might ease things out.

> readability + maintainability

I agree! I will fix it. Some concepts that you pointed out I remembered (but forgot while coding) from Clean Code (Robert Cecil Martin) about conditional encapsulation and the magical numbers.

Clean Code could be a good choice.

https://www.amazon.com.br/Clean-Code-Handbook-Software-Craftsmanship-ebook/dp/B001GSTOAM/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=

Oh, man. I just realized my second comment was providing almost the exact same information as my first comment, rendering it completely redundant. I hope I didn't waste too much of your time reading that.

But, hey, it's not like I littered your codebase with redundant docblocks when a language feature like hinting exists. That would be foolish and would go against the principles of writing clean code.