Clean Code: A Handbook of Agile Software Craftsmanship

Effective Java [0] is the single most important book I can recommend for any Java programmer. This article [1] gives an overview of some of the primitives you can use for writing functional Java. Lombok [2] is a very common library that makes writing functional Java much more ergonomic with its `@Value` annotation, but that might not be needed anymore with Java 14's Record types [3].

The book Clean Code [4] helped me a lot to really learn how to write clean Java, and many of these ideas directly translate into writing good functional code. One of the key takeaways was just how small functions should be which incidentally is a great thing to learn when functions are your main unit of composition.

Java isn't a purely functional language, so you obviously will always have some impurity regarding state/mutation. I personally try to do the following: 1. Keep all state in some top-level class and let everything else be immutable 2. Nearly every class I write is immutable 3. Follow common OOP principles like SOLID 4. Write reactive code with heavy use of Optional and Streams

Here's [5] an example repo of board game written using those ideas.

[0] https://www.oreilly.com/library/view/effective-java/97801346... [1] https://www.baeldung.com/java-functional-programming [2] https://projectlombok.org/ [3] https://www.baeldung.com/java-record-keyword [4] https://smile.amazon.com/Clean-Code-Handbook-Software-Crafts... [5] https://github.com/harding-capstone/logic

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 https://www.amazon.com/dp/0132350882/ref=cm_sw_r_cp_apa_i_8wOwDbEN2SQCM

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.

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.

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

If you just want to write better code literally, then consider reading Clean Code[0].

If you want to dive deeper in to Computer Science and become a Software Engineer, then there's a lot more to learn. Here's some short tips:

- Learn a few programming language for their paradism: Java (OOP); Python, Hashkell, Scala (Functional Programming), Rust (memory safety). You don't have to actually work on them, just need to be able to write some algorithm and know their key features.

- Read more code, especially those from high quality projects.

- Experiment a lot. Don't just read articles, blog posts. You have to get your hand dirty.

[0]: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

>What are your favorite resources out there that you turn to, that could be helpful in showing someone what a good review is?

Clean Code by Robert C. Martin.

This book covers all kinds of great stuff regarding correctness, maintainability, testability, etc.

I want to call your attention to something you wrote though.

>mid level engineers spending lot of time arguing about things that should not be the focus of the code reviews - e. g. variable names, code styles etc. In doing so, they are also not paying enough attention to the overall architecture, correctness, maintainability, testability etc. for the code they are reviewing.

This is a false dichotomy. Having code with well thought out names and formatting, enables having maintainable and testable code. It makes reasoning about correctness much easier. Same is true for the overall architecture. I would go so far as to say, you cannot have all of the attributes you desire, without having code that is easy to read.

Now, mid level devs are notorious for taking "Clean Code" too far, and inciting holy wars to purge the heathen sinners who dont conform 100%. Perhaps they just need their zealotry toned down. Names and formatting are definitely important, but not so important that they cant see the forest for the trees.

Also your methods are way too long!

• Main - 36 lines long
• WeekdaysBetweenTwoDates - 37 lines long
• BusinessDaysBetweenTwoDates - 91 lines long

​

So how long should they be? That is subjective. Some say as short as possible (around 5 lines long) others say no more than 20 lines long. Personally I think if you shoot for somewhere between 12-18 lines long you're ok. But for sure anything over 20 lines long you should probably start breaking up the logic into other methods.

​

Don't feel bad we all started out the same way. Read "Clean Code" to learn better coding techniques. Good luck!

If you forced me to pick a book: Don't Make Me Think is pretty important.

​

I would agree you don't really want a book to get started. Things change really fast in the web so the books you want to invest in are going to be more theory based rather than technology based, because the technologies that are being used right now can be phased out in a year or two.

You want to just get something up and running. Once you get comfortable with some basics you can dive deeper.

​

I like this course for getting ramped up https://www.udemy.com/the-web-developer-bootcamp/learn/lecture/3861606?start=0#overview

Usually these course creators continue to update to keep with the times so you won't learn anything too outdated. He has an "advanced" one also.

​

Two books I've heard are great but honestly I haven't read yet are: Clean Code and The Pragmatic Programmer

I recommend you to read the book Clean Code (https://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882). There are a lot of tips on writing code that can be read by other people, like you eight months in the future.

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

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.

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!

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.

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_3?keywords=Clean+Code%3A+A+Handbook+of+Agile+Software+Craftsmanship&qid=1559240556&s=gateway&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.

Clean Code Books: - Clean Code: A Handbook of Agile Software Craftsmanship https://www.amazon.com/dp/0132350882/ref=cm_sw_r_cp_api_i_2k80CbD4F4QHJ - The Clean Coder: A Code of Conduct for Professional Programmers https://www.amazon.com/dp/0137081073/ref=cm_sw_r_cp_api_i_Ml80CbREG48TD

Design Patterns: - https://sourcemaking.com/design_patterns

And of course, good ol’ practice.

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

https://docs.oracle.com/javase/8/docs/index.html

(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.

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

Refactoring guru is helpful: https://refactoring.guru/

Also, Clean Code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 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.

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:

js r = Math.random();

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.

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.

Another example is in move.js where you have these two lines:

js h = false; // no text setting g = false; // no move

In theory, code should be "self-documenting", meaning you shouldn't need a comment to describe what a variable is. In this case, you added comments to basically describe the variable.

To resolve this, just change the variable to be the description of the variable, essentially, like:

js hasTextSetting = false hasMove = false

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.

If you want to gain a lot of good coding habits, I would highly recommend reading Clean Code

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

> 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.

Also This https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882