What is Reddit's opinion of
Clean Code: A Handbook of Agile Software Craftsmanship?
From 3.5 billion Reddit comments
The following content includes affiliate links for which I may make a small commission at no extra cost to you should you make a purchase.
By popularity on Reddit, this product is:
313 reviews of this product found across Reddit:
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
>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.
Clean Code taught me how to write clean code. Cannot recommend this book enough, every place I've worked I've brought a copy and at least one coworker will borrow it and find themselves really questioning a lot of their decisions. It's also a great book to refer back to every few years.
edit: Truthfully, some was experience, seeing other people's code early on. Discussing with peers. Thinking about single responsibility et cetera. I don't think there is one source but the book is something at the top of the list.
It's written in Java, but for the most part, it's very transferable to C#. When I was a junior dev transitioning to intermediate, it was pretty worth my while. It's a relatively easy read and doesn't require you to be writing code or sitting at a computer (at least it didn't for me).
Feel free though while reading it to critically question some ideas as to how applicable they are in the C#.NET ecosystem, current best practices, and your day-to-day work. (For example, IIRC, he argues that you shouldn't prefix interfaces with the capital I. I still do that though and I find it worthwhile.)
Poorly written code generally doesn’t follow Best Practices, but includes issues like using inappropriate algorithms and data structures to manage data, and bad design decisions.
I recommend Clean Code by Robert Martin https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
He does a great job of highlighting what makes code readable, and maintainable, especially in the context of Java and OO Design and OO Programming.
I’ve heard some call it controversial. But after more than 20 years in the industry ( username relevant) I find him to be particularly on point and accurate. Personal preference aside, he knows what he is talking about and tells it like it is.
La filosofia descritta da te riassume la filosofia "all'italiana" : si massimizza il guadagno, minimizzando l'investimento. Questo non solo in termini di economia, ma anche di tempo e, talvolta, di istruzione.
Personalmente penso e ho trovato aziende (anche piccole) che hanno metodi molto più rigorosi per lo sviluppo (creazione di documentazione secondo un certo stile, ogni variabile deve essere assegnata con un nome preciso, ecc..). Poi, vabbè, ci sono anche aziende molto grosse con la metodologia AGILE , ma già creare una buona documentazione e seguire poche e semplici regole , fa la differenza fra il buon "programmatore" e il mitico cuggino.
Un buon libro per i colleghi Clean code , sempre che di inglese ce ne capiscano qualcosa.
Write clean code that is easy to understand. Commenting is, at best, a necessary evil.
Take this for example:
if((employee.flags & HOURLY_FLAG_ && employee.age > 50) employee.GetBenefits()
vs.
if(employee.IsEligibleForFullBenefits()) employee.GetBenefits()
Code can be self documenting; but it takes good craftsmanship and a lot of experience to make it happen.
I totally stole this example from the book Clean Code and its chapter on commenting, but it really drove the point home for me. Worth a read for anyone who wants to craft well written applications.
The problem is that to understand clean code they have to be able to differentiate between good and bad design. That insight usually only comes with the experience of having to modify badly written code. I can point them to Clean Code By Robert Martin. But most of it will go over their heads.
Powers you say? Who needs powers to defeat Yandere Dev when you already have access to the ultimate weapon...
Other than the standard naming conventions I try to use the project standards when joining to an existing project. I also use the best practices from Clean Code by Robert C. Martin, I could definitely recommend that one. Not only it mentions good naming conventions, but also other best practices.
You can Google around for small tips here and there, but there's no substitute for sitting down and reading a few chapters of a great software engineering book.
The best book I have ever read on this topic is called Clean Code by Robert Martin. I bought this book for every new hire in my software department and trained them on the principles of it. All agreed that it was the best level up for writing modular, maintainable, easy-to-understand code.
I study computer science, 2nd year bacc degree, one more year to go. I have excellent grades, but I still wasnt able to study more subjects and finish two years in this year although I had right to do it by Uni's regulations. The rule says that excellent students have a right to listen more subjects and finish studies earlier. They said they havent met anyone who wants to have more subjects in one year and although its great thing I am motivated, they cant accept my request because they arent informed enough. The reason why I did made request in first place was that I am pregnant with my first baby and it will hard for me to study and take care of baby at the same time. I dont know if I will be able to finish my studies next year, but I will try my best. I would really like to have this book so I can improve my coding skills and move out from this country so my baby doesnt have to live and learn in environment that demotivates you.
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...
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
No, it's not just about shortening syntax. Shortening syntax could be the opposite of clean code sometimes, like for example readability is more important than compact code in most cases.
It's about proper layering, error handling, naming, uniform formatting, testing and a lot more.
Here is a good book about it https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
There are a lot of great comments here talking about tooling and error handling which you should pay attention to. However writing tests, using CI/CD, writing error handling, etc. will only ensure that your code is correct. Correctness is necessary, but not sufficient for production code.
Production code is code written to be understood and by someone other than the person who wrote it. This includes things I’m sure you’ve heard such as comments, descriptive variable names, and doc strings, but it also encompasses how you approach writing code.
How detailed are your commit messages? Do you write descriptive PRs that explain why and how you are doing something? Are you taking the time generate formal documentation? Are you following the single responsibility principle?
The above is just a snippet. It’s a lot to learn, but that’s ok. No one expects you to know how it all. If you want to prod code, start practicing on your own. Write doc strings, write PR messages to yourself, make atomic commits. Go read clean code. There is a good reason it’s a classic.
Most importantly though, you should practice writing code with people. You will grow much much faster if you get other people’s eyes on the things you write. If your team doesn’t do code reviews consider contributing to an open source project. Preferably a smaller one because the maintainers will have more time to devote to you.
You should also read as much code as you can. This will teach you things like convention, design patterns, appropriate levels of abstraction, etc.
My C++ teacher in high school always had us write preconditions and postconditions at the top of our functions...and I basically haven't seen that since then.
I'm of the belief that scripts should be largely self-documenting by way of header comments, in-line comments, and precondition/postcondition comments. Large projects or things with external APIs are where I'd want to focus on external, comprehensive documentation.
I'd really, really recommend people check out the book Clean Code. When you take the time to really think through the metaphors you're establishing with your function/class/variable naming, you can find that better naming can result in code that feels like it writes itself.
Easier to read, easier to debug, easier to share.
Less lines is not inherently better. In fact, it can quite often be significantly "worse". Clever is cool, until you have to look back on it a year down the line.
If you just started, though, don't worry too much about it. If you want a introduction to code style, I always suggest Martin's Clean Code. It's an easy read, and you shouldn't take anything he says as absolute fact, nor will you understand everything he talks about, however he presents his opinions on a lot of topics that are good to think about as you learn.
Yeah it's understandable, creating a clean structured code pretty hard and "advanced" I guess.
I'd also recommend Clean Code it's less about React and more just in general.
Kirja mikä omasta mielestäni on yksi tärkeimpiä lukea, jos jotain meinaa lukea.
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Tämä vain minun mielipiteeni toki, ja ylempi kommentti ei niin totisesta aloittamisesta saattaapi auttaa motivoitumaan paremmin.
you as a developer do not control the code review practice in your company
read clean code handbook's (https://www.amazon.ca/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) section on comments and documentation. This isn't some weird out of left-field opinion.
there are some cases where comments are good (explaining why a weird piece of code is there). but those should be few and far between
i assume u mean this clean code book? It seems like a good book for a side read but even to determine bad code, you first need to be able to write code.
my personal view is that you can go over this once you are able to write your own code to tackle problem statements. reading it before you are able to do it would simply be a waste of time.
another book for side read i would recommend is to find a book which teaches you how to write comments but even that is low priority till you learn the rest of the stuff.
I have been on the hiring end of backend development. You do not have to be a "master of algorithms". The main skill you must have is writing cleanly. Backend is more strict on this regard. Look at this book to learn more.
With regard to algorithms, it is enough to just know what is avaliable to you. You will rarely have to implement an algorithm from scratch so just knowing the names and what they do is more than enough. If you are pressed on the matter, you can just say "in a real world situation, I'll google it"
However you should know O(n) notation for algorithms. It helps you choose what is better for your current problem.
Even though you don't have to be a "master of algorithms" you must be a "Master of Data Structures". There is not a lot to memorise but it is a must have knowledge if you want to transition to the backend.
I highly recommend reading this book: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
If you write bad code you’re shooting yourself in the foot down the line. And it’s a lot harder to go back and fix bad code than write good code to begin with…
I highly recommend the book Clean Code. It was a fundamental resource for me back in school, and if I recall the later chapters are focused specifically on object-oriented design.
Clean Code: A Handbook of Agile Software Craftsmanship https://www.amazon.com/dp/0132350882/ref=cm_sw_r_cp_api_glt_i_91XAKS3RRSH54BZMHFYF
Is this the book you recommend? I’m beginning my self taught journey and also looking into reading as many CS books as possible.
> Kannst du ein Buch [...] empfehlen?
Wenn du noch nichts in die Richtung gelesen hast, dann alles von Bob Martin, z.B. Clean Code
It’s basically a bunch of different practices to keep your code clean and maintainable.
It’s not a bible/law, and there are points I disagree with such as ripping a function into so many small pointless components, but a great read for fresh juniors and in general
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Thanks for the kind words! The important thing to note is never stop learning and don’t lose your curiosity, try purposely breaking things, see/note what happens then fix it, watch some videos and read docs on the debugger features and functionality to make your life easier
I hear you, but your position sounds too idealistic. In fact you are the first person I see who seems to be fond of comments. I've always heard nightmare stories and a lot of frustration from everyone else.
My position is not based on my own multi-decade experience writing software professionally, but it is based on the experience of developers that have, that shared their experiences.
The main one being Robert C. Martin. I'm sure you are familiar with Clean Code? I really suggest watching those videos I linked as well if you haven't.
The main argument (at least when it comes to comments) is that if your code needs comments to explain what it does and how its supposed to be used, then its probably a convoluted mess. The solution is not to try and explain the mess with comments, but to make it not convoluted and clearly understandable by itself. If you achieve that, commenting your code simply does not make sense, because even the most carefully crafted comment will only be stating the obvious, which, I think we agree, makes it utterly unnecessary.
I've been going all in on this idea, and I quite like it. It does require a fair bit more work than simply writing code that works, then commenting it, but I've found that it makes the codebase a lot healthier.
There's a really good book that goes into this, Clean Code.
"helper methods" is the wrong way to look at it. Instead, look at it from the level of abstraction, like an outline. Why do people create outlines, instead of giant blobs of text?
The entry point should give a high level overview of what's happening. Each method should be like an invitation, "if you want to know more".
That's where guidelines come from like keep the indentation level low and keep methods short. Because with more than 3 levels of indentation or really long methods, its really easy to lose the point of what the method is trying to achieve, which makes the code harder to read and therefore harder to maintain.
If you want to code then first learn software design patterns and OOP principles. Because those apply regardless of what language you choose.
I’d also recommend reading https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=mp_s_a_1_1?dchild=1&keywords=clean+code&qid=1631071206&sr=8-1
To save yourself from yourself.
Once you get a handle on operations, I would recommend you check out this book. I used to be really intrigued by really neat algorithms until I got a job working with other embedded developers. I learned real quick that crafty code will get you nowhere, while *clean* code helps your team and helps you look back and understand your own code.
Clean Code: A Handbook of Agile Software Craftsmanship https://www.amazon.com/dp/0132350882/ref=cm_sw_r_cp_api_glt_fabc_3NW4HW6QCS83SQT09Z2V?_encoding=UTF8&psc=1
Last time this question was asked everyone was raving about this book. I can’t say i personally have read it but it’s on my book list of books to get
- main.py is almost 500 lines long, but it can be easily separated into multiple files. There are comments throughout the file e.g. """ IMAGE DRAWING """ which is itself an anti-pattern.
- Params and globals should be in different file that's for sure. And they are essentially the same thing in context of this repo, as far as i can tell.
- Function naming . E.g. color_select here "select" doesn't seem like a verb and "select_color" would've made more sense, but what function actually does is "Draws the color selection display", which is not really obvious. From description it seems like class ColorSelectionDisplay: with draw() method would be more suitable.
- Dead code. Pretty self-explanatory, e.g. # print(hsv_color[2]) or # hsv_color = rgb_to_hsv(color) . Dead code is alway a trouble, when it's not yours, or when you continue on working on a project after a significant break. You have to wonder what's the purpose of it. Should it be uncommented or deleted? Why is it even in here?
- Another thing to notice about color_select function is that it's very big. It's more than 100 lines, but also has comments like # Draw hue display and# Draw hue display - exact places where you should split it.
And that's not even the end.
Don't get me wrong, I love the project and all the effort that's put into it. It's really cool to see how people create interesting projects on their own, and not to mention those kind of projects are probably the fastest way to learn.
General advice that you probably hear very ofter is to read "Clean code" by Robert Martin
While learning is always nice to have a side literature… i recommend https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=mp_s_a_1_1?dchild=1&keywords=clean+code&qid=1628136279&sr=8-1 never read it but all my teachers suggested it.
Your view of software dev severely clashes with modern conventional best practices. Human readability might be THE most important consideration while writing maintainable software. Maintainability is key to efficient teamwork, feature additions and bug fixing. Good code documents itself. Code that relies on documentation to explain it runs a heavy risk that the documentation will eventually fall behind and sink into irrelevancy and become technical debt. Here's a book for ya.
Depends if you want to you'd the variable outside of the function scope, If the variable will only be for the function keep it inside of the function, To learn more about clean code I recommend reading: "Clean code handbook" https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
I've been using Python for about 10 years now to build the back end of web apps mostly using Django or Flask, but have dabbled a bit with Pandas and do somewhat agree with you that it encourages non-Pythonic practices. At my company I've interviewed many people, some of whom came from a more data-science focused background and having a lot of experience with the library and I've found that their overall coding style has been sloppy and what many would consider unmaintainable.
So while I do think I would benefit from knowing more about the inner-workings of the library, I can't help but agree that it encourages bad practices. I don't know why exactly, and it could just be coincidence that people who major in fields which just so happen to use programming languages like Python to solve problems and decide to apply for programming jobs are in practice sloppy coders.
One of my managers earlier on gave me a copy of this book, and while some of it is fluff, I benefited a lot from the code practices it preaches: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Yeah, that’s what you’re supposed to do; it’s mostly for clarity and readability, which also helps a lot with maintainability and debugging.
The blocks inside conditionals and loops are good candidates for extracting into their own functions, for instance. Beyond that, try to make sure each function is only responsible for one thing, and turn into a function anything which might be vague or require clarification.
I would suggest reading Clean Code by Robert C. Martin :3 It focuses a lot on Java, but it still has a lot of good advice regarding clean code and software architecture in general (chapter 3 talks about functions, by the way).
make sure the logic is sound. you may not catch all errors in the code during the code review, but you might spot some errors that get missed
clean, easily understood code, something like clean code by uncle bob can be a good resource. this basically covers 1 - 4 of what you're looking for
adherence to SOLID/DRY principles
easy optimizations such as caching intermediary results for general speedups if necessary, list comprehensions instead of for loops, etc
If you can't understand your own code then probably you should read Clean code/Architecture by Robert Martin) and other recommended by Amazon. Ability to read other people's code highly depends on its quality. I would not recommend "just read more code" until you understand how good code looks like, the fact that someone put their code online doesn't make it good automatically.
> If you have any other tips or have any opposing views to any of these rules I'd love to hear them and discuss them!
These discussions get copy-pasted all the time, from one blog to the other, from one forum to the next. Your post is no exception as it is also copy-pasted from somewhere else (some parts of it, at least). Some bloggers/posters have the decency to quote the original references, but to be fair, after tens of copy-pasting cycles the references can get ~deliberately~ lost.
Here is the main reference for you or anyone else: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
I'd read Clean Code for a good overview. It would still be helpful to know what parts of your code have been less than readable in the past, so I could make specific suggestions.
Thank you, which of those do you recommend to start with?
If you're interested in learning more, I'd recommend reading Clean Code: A Handbook of Agile Software Craftsmanship. It will give you a big upper-hand in projects like this one.
I disagree, and one of the most recommended books to improve at coding does as well. Take a look at “Clean Code”, they explain in great detail and with many arguments why you should avoid comments as much as possible (sometimes they are unavoidable but 90% of the time you should not use them). Obviously you need to code better and in a certain way to not need to use comments, I’m not saying just to suddenly stop using comments, but code in away that code reads like a book and it explains what it does by itself without a comment.
Also, comments add more work, not for the two seconds you need to write it, but in maintenance, when you need to go and change it because what you wrote in the comment is no longer true. Most of the time you won’t change it because someone else wrote the comment and you don’t want to remove it “just in case”.
Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) https://www.amazon.es/dp/0132350882/ref=cm_sw_r_cp_api_i_y5jgCbB1XDKPD
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 https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 like
- variable names
- formatting
- functions(!)
- tests
Smaller functions are generally better. Having functions possessing a single responsibility helps testing when the program scales in scope and size. Adding more code means less stuff can break. Helps readability too. I suggest this. Really good book!
They do a good job trying to cover best practices. Can anything truly cover everything?
Without assuming your prior knowledge, I'd suggest looking through codebases/issues/PR's of large libraries in the react ecosystem. Conversations between maintainers and contributors tend to be very educational. Some good repos to peruse - redux, react-virtualized, react-router. /u/acemarke can also hook you up with his great lists/links that you can peruse.
And of course the ultimate recommendation for best practices - Clean Code.
No one would ever do that though...
Have you not read Clean code?
https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
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.
Ah k, perfect amount of time to read a book or two. I would definitely recommend reading Clean Code by Robert C. Martin. Regex and Exception Handling is something that you can quickly google search when you are at work. Otherwise, enjoy the time that you have from now and start of work!
laravel in general and laracasts in specific encourage all sorts of insanely bad practice. i would not take any of their advice seriously in terms of best practices. i would suggest getting a book like clean code (https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)
> So your point is .... people should adjust their code base in a way that it becomes easily readable...
Yes, that is my point. You should always strive for your code to be easily readable.
> This feels like fighting the consequence instead of the root of the issue.
No, that is exactly what you were promoting by validating this (poor code style) as a solution for having too long functions (poor architecture). Which is fighting technical debt by introducing more technical debt.
What I'm suggesting is to refactor your code so that it makes structural sense, taking ownership of quality and maintainability. If using this is proper code style for you, then great, refactor to use that. But if you're using it as a crutch to not have to refactor otherwise unreadable code, then think twice before committing it.
Recommended reading: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
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.
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.
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: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
This book. This book honestly has the answer to all of your structural coding questions. You will spend your entire career trying to make code that follows the standards herein, but it's not really possible for a live project. And that's a good thing. You don't really need to look anywhere else.
Game development is a bit different from web dev in a sense that there's a lot of logic going back and forth that has nothing to do with displaying stuff inside browser. It's also a necessary (and not merely an optional) part of your program now. So you can't just hide error messages completely if something went wrong hence point of accessibility without enabling js no longer applies.
Rest however is mostly similar - not cluttering global namespace, functions doing exactly the thing they are named after, making individual functions and objects relatively simple etc. Basic guide is always the same - code in such a fashion as if the person maintaining it in the future is a psychopath that knows where you live.
Regardless of what you are building you probably should look at books such as Clean Code. While it doesn't deal with javascript pointers given in it are applicable to any language and project.
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.
A friend said he read in a book (I think it was this one) that you should avoid commenting your code as much as possible because that means the code isn't "clean" enough. If a code is well written, it will be self explainatory what the purpose of the code is. Not saying you should ditch commenting all together, but just that this might be what the gatekeeper is trying to express.
I highly recommend this book, which kind of contains all that feedback. Don't get put off by the shoe horning of the word Agile into the title, its not really got anything to do with
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
I got it because a place I ended up turning down an offer from gave this and Head First Design Patterns to all new hires regardless of their previous experience. The copy I bought for myself has been passed around my office so much that it hasn't been on my own desk since I about a month after I came in.
Hey, thanks for this constructive feedback!
> First thing I did is went straight to tests. +1 for having tests!!! People truly don't get how important it is.
I too really think that tests are critical. My first project that I worked on was relatively large and with no unit tests (it wasn't very testable either)... 90% of the cases I heard "Well, this used to work. Somebody probaby changed something." would be avoided If we had good tests. Though I don't think that I know how to write good tests. Can you recommend some good book on this topic?
> I think a package that you may find useful for your tests is Faker...
Well I considered using it and it could replace many literals from my tests but I don't know how could I test table rendering with it since it generates random data.. any suggestions?
> I would suggest removing comments.
Do you mean the inline or the docblock comments?
> highly suggest reading this book which harps on this topic a lot, it may be one of the most respected books on software: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
I've heard good things about this book but I didn't have time to read it. It's time already, I'll upload it to my kindle tonight!
> You used types!!! Awesome!!!
WE WANT GENERICS!
> I saw some nested if-statements...
I usually have a rule to write maximum 1 nested if (else) statement. And after seeing the tremendous amount of nested if else statements some devs write I used to feel like code qulity ninja :D But maybe it's time to reform my rules^after^I^finish^reading^the^book .
> In your Row.php class (and some other places), you have a "new" declaration. "New is glue,"
Well I used the new keyword to instantiate some data structures. But I don't think that "New is glue" rule applies to data structures. Isn't it like creating new array like $rows = []; ?
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.
//creates 5 boxes with random colors Random rand = new Random(); int randomNum = rand.nextInt(i - mins + 1) + mins; changeColor(randomNum,100+(150*i)); g.setColor(curColor); g.fillRect(100+(150*i),500,100,100);
Whenever you find yourself writing a comment like this it most likely is a candidate for it's own method. Then you can get rid of the comment and use the method to describe the code within it. This makes the code cleaner and allows people to drill down if they need to see details while it's abstracted higher up.
An example
File file = getFile(fileName); String json = convertToJson(file); String result = postToService(json);
This imaginary top level method is much easier to read and immediately gives the reader the overview of the class/application
Check out clean code
https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Even if this book is for Java, that's the best one for OOP
Clean Code: A Handbook of Agile Software Craftsmanship
By Robert C. Martin
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 (https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) 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.
I double down on Powershell now, but I got here from other languages. The good news is that once you become proficient at one language, it is much easier to pick up another. I would focus on content that makes you a better programmer. Languages come and go over time, but those are lessons that you will take with you.
Here is a good book that I enjoyed and it helped shape the way I see code: Clean Code http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1464905147&sr=8-1&keywords=clean+code If you read that and come back and look at my examples, I am sure you would see the influence.
I am sure others can pipe in here with other good programming concepts to learn that translate well to Powershell. With that said, there is a lot of value in learning other languages. So often we think about problems in the language that we know and when we know other languages, we can have a larger capacity to see problems in different ways.
Technically, architecture. Objects and arrays and all the neat stuff you can do with them. Learn about the Constructor Object, how to structure code. This book, I recommend it.
Clean Code Amazon I wished I wrote my code as described in this book when I first began programming. Many hours wasted re-writing my crappy code. My code is probably no better, but at least I can read it
I'm sure you're doing this as well. But I know where I work coding ability is something that will get you through a phone screen. You should focus on some designs paradigms , clean code practices, test driven development etc that will set you apart from your peers in an interview.
Languages don't really mean much most of the time unless it has performance based domain knowledge such as c++
I've found this to be a good read
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
>I know not doing it hurts readability but honestly, when there's no collisions, and only one instance of each type in the context, then I really don't feel like it that's important: 'It's an AbstractMethodFactory - that's all you need to know. If you are curious about what it does you can bring up the javadocs.'
Documentation is about what it is not how it's used.
Good variable names should describe what it's used for, especially if it's not obvious from context. Using "i" is fine for a loop variable, but for things like class fields they should be named by what they do.
If you don't then a few months down the track you will come back to the code and it will take you ten times longer than it should to work out what is going on and how things work, and this is when it's you own code.
edit: if you are really interested in tidying up you style, i suggest you check out Clean Code. I can't recommend this book enough.
Read this Clean Code book. It teaches in Java but the concepts translate to Python perfectly. I had been writing hundreds of thousands of lines of Python on a team but reading this book really solidified some excellent best practices and made me better than even that experience, like:
- Use good, meaningful names like
heightInCm - Use comments only as an admission that you couldn't express something with code.
For example, instead of this:
# check to see if the thing is big enough if myObj.size > 5 and myObj.length > 7: blah()
prefer
if myObj.isBigEnough(): blah()
etc. It's very enlightening.
The SQL experience is extremely portable, and SQL's not going anywhere.
> I'm a solo developer here with no work and no experience doing team development.
That .... sucks. At this point in your career, you should be learning from other developers.
> system programming or test which I'll usually pass but it won't be "up to their standards."
Essentially, what they're saying is your code is functional, but from a code-style perspective, it requires a lot of work. Read "Clean Code" by Robert Martin
> I can't handle being miserable and doing nothing at my desk all day.
It may be an opportunity, in the sense that you can learn whatever the hell you want during that time. In contrast, I tend to be so busy with work, that I don't have time to learn languages which I really want to add to my skillset.
Though, obviously, I think working on a team would benefit your career more.
Getting employment this early in your career is tough, but hand in there! It gets easier as you progress through your career.
I think this book is perfectly fits for the topic: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 . Although I also have doubts about the professor intention, I was a quite surprised about the book can openly speaks and presents samples about making the code larger, but more maintainable and readable. I think it's always about finding the good balance, and not just about applying the proper or the most efficient algorithm. The book is worth to read so your code should be;).
The thing that helped as a developer and one of the first things I teach my juniors is not learning how to write {insert language here}... But instead to learn the art and how to write code cleanly.
I know that may not make much sense... Take a look at books like Clean Code by Robert C. Martin. It will help improve your productivity and your understanding of what write code is about.
Making code work is only half the battle; The other, and most important part IMO, is maintaining it.
tldr; Learn the art of writing code, not a language.
The quickest and cleanest definition on proper commenting (and proper code) can be found in:
Clean Code: A Handbook of Agile Software Craftsmanship
General Rule is that you never document the what, but the why if it's necessary.
Javadoc or the equivalent in other languages should be precise.
Comments should be used like spices - sparsely. Too many will just add visual clutter.
Comments have to be used with care as they need to be maintained along with the code. Comments usually become obsolete and wrong pretty quickly.
This can actually be generalized to keeping things DRY (don't repeat yourself) and avoiding magic numbers. Hard coding in values (even strings) is a magic number and those are something to avoid as they make change hard. The same can be applied to copy pasted code. Imagine if you had validation code or something and you copy pasted it into several locations. If that changes later you have to go into all those areas to make the change. If you put it in a single function that all the other spots reference, it's one change later.
OP - Basically everything in this book I wish I knew
I would agree that usually it is, but not always. I've been reading "Uncle Bob's" Clean Code recently, and have come to adopt many of his ideas.
So as opposed to...
- (void)viewDidLoad { .... self.widgets = [[NSMutableArray alloc] init]; self.gadgets = [[NSMutableArray alloc] init];
self.navigationItem.title = @"Inventory";
self.tableView.backgroundColor = [UIColor redColor];
[self fetchWidgets]; [self fetchGadgets]; ... }
I'm more likely to have...
- (void)viewDidLoad { ... [self initializeData]; [self initializeView]; [self fetchData]; ... }
- (void)initializeData { ... self.widgets = [[NSMutableArray alloc] init]; self.gadgets = [[NSMutableArray alloc] init]; ... }
- (void)initializeView { ... [self initializeNavigationController]; [self initializeTableView]; ... }
- (void)initializeNavigationController { ... self.navigationItem.title = @"Inventory"; ... }
- (void)initializeTableView { ... self.tableView.backgroundColor = [UIColor redColor]; ... }
- (void)fetchData { [self fetchWidgets]; [self fetchGadgets]; }
etc.
Very small, well defined functions that serve 1 thing, and if they attempt to do 2 things, then breaking them apart. However, it can lead to a lot of functions. They're all very readable of course because of their size, and if they are named well, no comments are needed. However, I'm never too sure how best to organize them and where to best slot them into my code.
I would highly recommend you read this book. A colleague and I follow it religiously at work and it does a good job of prescribing universal good coding practices while recognizing that some styles or conventions are borne out of historical technical or structural reasons that modern day IDEs do away with.
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Based on that I'd probably already offer you an interview for a development job.
I'd recommend you focus on the skills required to work in a development It sounds like you've got the making code work side of things down, so focus on writing code other people can read and using source control if you don't already.
Buy or borrow a book called Clean Code this contains alot of advice how to write clean + readable code.
It would have been more appropriate for him to teach you the techniques and buy into his changes before just doing them.
There's a really good book if you want to learn to be a better programmer. http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1428719474&sr=8-1&keywords=clean+code
It doesn't really get into design patterns so much as teaches you how to write clear, concise code.
this book was a godsend for me in organizing clean and legible code.
What it has to say is avoid using "this" whenever you don't need it. The only place you should use it is in a constructor where there is a parameter name that is the same as your class field name.
So I'd say don't use "this" in this case.
Functions need to have their return type defined in Java, even when there is no return type (void).
If your methods don't need any instance specific values you may want to consider making things static (this is equivalent to global functions and fields). It really depends on the bigger picture.
Hope this helps
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.
Problem with code is that if you write it you will (or should) understand it. I am guessing your senior dev has written a lot of the existing code and probably doesn't see much problem with it. They may also feel quite defensive if it is criticised.
It is very hard to write code that is generally understandable. We have millions of copies of the Clean Code book in the office and everyone is encouraged to read it to improve code style. It might be useful to you.
I think the best way to approach this is to rewrite a small section of code and say to your senior dev that you have been reading about the benefits of re-factoring and ask for a code review of your changes. If it was me and your code was easier to read and understand then I would accept the change.
Thanks for the luck, I have a feeling it will be a good review, but I know I have a lot of building to do on my current skill set. It's really hard to know where to improve in the first 6 months since they provided zero feedback, which I find concerning because it's bad form to allow one of your employees to preform "sub-par" work for any length of time and not do something about it (I put it in quotes because I feel like your getting a raw deal, these are normal developer speed bumps). I believe personal development is a major part of a young devs growing cycle. Working on a small team probably doesn't help your situation. Do you work on projects outside of work? If you are open to building your development skills, I highly recommend reading Clean Code (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 or you could find the "free" pdf version online). One quote from the book talks about "taking the time to go fast" which sounds like an oxymoron but the more you think about it, the more it makes sense. How do you feel about your work? Do you agree with any/all of the items they listed in the review? I think the way they wrote some of the "issues" down will make you feel more stressed when coding/pushing to version control, which can negatively affect your output. Have you created a plan on how to tackle the problems? I think that might be a good first step.
> 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.
> 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:
>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.
Only problem is that there's bad books out there and if you're reading one a week perhaps you will be more likely to expose yourself to them as there's not so much time to research which books are good. Perhaps it'd be better to read one excellent book every month.
Also, book learning isn't for anyone. I don't think I've actually managed to read a programming book cover to cover, however I am an experienced web developer.
Ooh, one book I did read...
Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin)
If you plan on writing software and not necessarily expanding the field of computer science then take a look at the first few chapters of Clean Code: A Handbook of Agile Software Craftsmanship. It helps with keeping your code readable, reusable, modifiable, etc.
I'm reading a book entitled <em>Clean Code</em> that talks extensively about naming conventions, how to organize, prevent duplication, and other such things. It uses the word "Agile" in the title, but I'm not really sure why because you don't need to be using Agile to write clean code...
It's focused on Java, but I think most of the principals apply to any OO application.
Thanks for this post, I'm always looking for ways to improve my code, and I'll definitely take all of your points into suggestion.
RE: Point 1 - surely the module should fail to load if dependencies are not met? Hence why I have a dependency checking function: DEPENDENCY::require_classes('PDO'). I'm generally really confused by this point, it would be really good if you could explain more.
Point 3 - It isn't serialized, is it? It's just an array of "extra" data that hasn't been serialized yet, and JSON was the fastest way to do it?
Point 5: Do you mean in the passed array or the SQL itself? I like them in the SQL, but agree with you for the former.
Point 6: I've always been taught to DocBlock everything, and thought this was a bit much, but got a little obsessed with pretty PHPDoc output. Other decent coders agreeing this is too much is kind of a relief if anything. Do you have any examples of great code? How would you change my session.php, exactly? Is this the book you mean?
Point 7: Didn't realise PHP even had this, AWESOME.
Aye, I didn't mean anything to that degree. I find relying on session too much was quite lazy and unnecessary.
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: https://github.com/getify/You-Dont-Know-JS/tree/1st-ed
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).
> I also feel like there are principles and high-level knowledge of "craftsmanship" in software (specifically cloud services for me) that aren't taught in school
You got this one on the nose. The most compelling thing that I feel like I got from my degree was the training in structured problem solving and managing abstract concepts. The greater patterns of software engineering were nowhere to be found. Even the common patterns like source control and unit testing weren't really emphasized in the "top university" program that I graduated from the mid 2000s.
> but are also never clearly laid out on the job either
I'm sorry you're having this experience. I feel like being able to learn craftsman type knowledge from your job is a crapshoot. You'll either have opportunities to learn great lessons from superiors and projects, or you won't, and it seems like it comes mostly from the engineering culture at your company. But, fortunately this isn't the only way to level up in this way.
> and I'm wondering where the principal/staff/architect folks osmose all of that knowledge from? Is it just years of experience, or does it take significant extra learning and interest outside the job?
Realistically it's a combination of things.
Reading about engineering practices - both basic and advanced - will get you a long way. Books like Clean Code, Clean Architecture, Design Patterns, Domain Driven Design, etc can help you develop an understanding and appreciation for some of the broad patterns.
Working on projects where you can experiment with the above practices and patterns is critical. The things you learn are just tools, and each one has strengths and weaknesses depending on when you apply them. Trying things and failing, and trying things and succeeding is a great way to internalize what works, and when.
Having deep discussions on practices, theory, and lessons learned with the folks that you consider to have these skills will accelerate your learning. Ask the folks around you that have these skills to mentor you. Great engineers are often looking for talented peers who can take advantage of the lessons they've learned.
> I'm trying to develop a more zen-like mindset, like "Accept the fire hose of information, accept the chaos, don't care about appearing 'smart' or 'dumb'", but it is difficult to be a monk.
There are a lot of reasons that places can feel like firehoses or chaos, and it's not always because it has to be that way. Software is almost always complex, but at the core of the software should be coherent models that represent a real life domain. If those software models are poor proxies for real life, working on and maintaining that software is going to be much more chaotic than it has to be. Figuring out if the chaos is coming from the domain itself, or from poor software modeling of the domain is a valuable insight.
> My question to more experienced devs: does this ever get easier? Or is this why it's tempting to settle on one project for a long time?
Many of the craftsmen and craftswomen of the trade have internalized a large number of tools (patterns, behaviors, tricks), and at that point it does become easier. When every project that you look at can be reduced to a set of familiar patterns and antipatterns applied to some domain, it gets both easier and more fun. You start appreciating even seemingly mundane projects because of all the nuance that is available between the domain and the tools you have to tackle it.
Hopefully this helps.
Without a formal CS degree, you most likely lack the fundamental knowledge that engineers will have about the field. I am self taught. I have been conducting technical interviews for 3 years now as a lead. Here's some topics I cover in interviews that are language agnostic:
- The 4 fundamentals of OOP (and getting in depth on each one).
- The Gang of Four's original design patterns (I usually leave out the obsolete ones).
- Architecture patterns. This can be as simple as "tell me a stack you've worked with" or as complex as getting into microservice strategies (we're a microservice shop, it's it's apropos).
- SQL, typically surface level just to demonstrate understanding of normalization but to sr devs I also will include the CAP theorem and ACID stuff.
- SOLID principles *** I ADORE the SOLID principles and I typically write off any engineer who doesn't know these.
- O notation and some basic questions on it.
- version control (git)
The Imposter's Handbook is a great way to start to fill the gap. From there, you can look into some Uncle Bob books like Clean Code. I would suggest reading a book like Imposters Handbook then diving into the subjects he touches on in depth if you want to learn more. Many of those topics you'll find information on for free, like algorithm history and building.
I've been in interviews that go both ways: very broad and very specific to a framework you're being hired for. It really depends, but getting the basics down is so very fundamental to this career. With the understanding of those things above, you can learn a new language very quickly. You can write clean, maintainable code that employers will value. I hire based on SOLID and design patterns because I want PRs that have clean code in them. I don't want the next person to inherit a mess like I tend to inherit. Without a BS on your resume, the red flag is in these areas. Anyone can follow a tutorial and write code. Coding for companies is a different game because there are many people working on the same thing at once. This cooperation and common vision and insight is the hardest quality to find in a programmer.
​
EDIT: After reading a few replies, I realized I must not have been clear. This is only the language agnostic portion of what I interview for. I still do coding exercises. We whiteboard pseudo code or we get into language/framework-specific questions. Out of an hour, I will typically do about 15-20 minutes of these textbook style questions. The rest is interactive problem-solving work.
This one is good and frequently recommended:
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
I recommend this book: Clean Code
We gave it to every new data scientist we hired at my last company.
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?
In all seriousness, write clean code.
I haven't read it yet, but Robert C. Martin's "Clean Code" is well recommended and might fit your bill (Note I believe it is generic, i.e. not Python-specific).
https://smile.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
And someone's brief summary of what they learnt from that book:
https://medium.com/mindorks/how-to-write-clean-code-lessons-learnt-from-the-clean-code-robert-c-martin-9ffc7aef870c
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Please read this, I beg you. If I have to refactor one more python file written by a self-taught programmer that refuses to write classes I will grow a brain aneurism.
If you don't want to buy it, hypothetically someone on this site might be able to DM a pdf to you, but that probably violates some rule so they wouldn't tell you outright. Hard to find someone like that, unfortunately.
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
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Isn't this clean code?
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=nodl_
Specifically… learn how to use unit testing to solve the problem one piece at a time so you don’t have to pre-plan how to break it into chunks.
Books I can personally vouch for are:
Composing Software by Eric Elliott is really good imo.
Clean Code by Robert Martin
You Don't Know JS Yet by u/getify
Here is a decent looking list of books I haven't personally read but look pretty good.
For sure this site gives you great directions in deciding what to learn:
I suggest to give a look to frontend, backend and react tracks to start.
Beside this I suggest you to get your hands dirty with some personal side project or contribute to some open source repo (if you need one, I have one ;-) ) and try to do things.
At some point reading Clean Code is mandatory. Do NOT get the Kindle version because code examples are difficult to follow.
Robert C. Martin book - https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 and for "clean architecture" you can check youtube for his lectures or Python lectures related to his ideas.
For UX/web UI - https://en.wikipedia.org/wiki/Don%27t_Make_Me_Think
Definitely Clean Code. And probably the Pragmatic Programmer (take a look at the books on the list, they are all good reads)
No, Clean Code as defined by https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Check out Clean Code. Some fun tidbits are below.
>Why am I so down on comments? Because they lie. Not always, and not intentionally, but too often. The older a comment is, and the farther away it is from the code it describes, the more likely it is to be just plain wrong. The reason is simple. Programmers can't realistically maintain them.
>
>Code changes and evolves. Chunks of it move from here to there. Those chunks bifurcate and reproduce and come together again to form chimeras. Unfortunately the comments don't always follow them -- can't follow them.
>
>The proper use of comments is to compensate for our failure to express ourself in code. Note that I used the word failure. I meant it. 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.
Comments can often be a code smell. There should never be redundant comments. Your method name and signature should tell you those 3 things you're saying you're writing comments for on simple methods. Comments are code, which means they have to be maintained. Programming 101 is don't repeat yourself. If you write a comment that is already clear in code you just repeated yourself.
I know this is a very polarizing topic, and I think last time I brought it up on this subreddit people flipped their shit. But that's my opinion, and this author's opinion, and I agree with it. Comments were ultra important in college, you were literally graded on them, which I think is why a lot of people defend them. Because those people are students. I thought this way once as well.
Every time you write a comment, your first thought should be "Before I comment this, is there a way I can refactor my code to make it clear/obvious what this does?".
If your methods are so big or complex that you can't understand them quickly, then you should ideally be refactoring those methods so that you can.
Clean Code Book for learning how to code well and to learn a few of the SWE buzzwords like SOLID and DRY.
Design Patterns to get through those Java/OOP interviews, and to get acquainted to writing code often seen in enterprise systems.
Introduction to Algorithms if you want to take a really deep dive into algorithms.
Pentru proba practica iti recomand sa citesti o carte de clean code, de ex. https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Te va ajuta si la interviu dar si dupa in cariera.
Honestly, I would suggest reading and listening to as much content as possible. The more you hear the correct lingo, the better understanding you will get. Digital Analytics Power Hour is a good podcast.Applied Artificial Intelligence (A Handbook for Business Leaders) is a good book for introductory concepts. Clean Code is a good book to help you learn good programming concepts. This blog has a good list of tech/data resources.
A lot of great results on this page. I also recommend clean code it's super easy to follow along, and provides excellent practices to implement in your daily coding.
This set of books written by Robert C. Martin should be a mandatory read for anyone before looking for a job or in their first weeks after getting one:
https://www.amazon.com/gp/product/B0051TM4GI/ref=dbs_a_def_rwt_hsch_vapi_tkin_p1_i5
The last one despite having C# in the title uses very old version of the language for the examples. But the principles and theory presented by the book are applicable to any (don't quote me on that) language.
That's some ugly looking code ya got there!
Ok, if you are look in specific for book/s for a more general understand of programming and good practices in general, in my experience these are two useful references for understanding why some decisions are better than others and so on.
Is a more general and pragmatic way to think of how you should approach code and architecture, not only for C++ but for code programming.
Hope that's help for your search:
Clean Code:
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Clean Architecture
https://www.amazon.com/Clean-Architecture-Craftsmans-Software-Structure/dp/0134494164
The clean code series is pretty good https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
It's not idiomatic go, but works across most modern languages.
Just because you can't explain what good code is, doesn't mean that others cannot explain what good code is.
The book Clean Code is considered a classic.
For a python specific intro, maybe this:
https://www.geeksforgeeks.org/best-practices-to-write-clean-python-code/
Once thing is industry level education and another thing is academic level education. Sometimes, the latter can't keep up with the former. And that's OK. Not all universities can do that. That said, it doesn't mean you can't go on and do stuff on your own.
Theory is important because you will not be oblivious to what is being discussed at the job when you finally get it. That's why you apply for internships and junior positions.
When you are in the fundamental level of a job, you learn quite a lot; the concepts learned at the university start to click and you won't feel ignorant to the job's demands.
You know what I do to close this gap while studying at the university: I read books on what interests me in the positions I might want to look for in the future. The university gives you the curriculum. And sometimes professors and learning designers get lazy and don't include important stuff or the assessment portion of a course is off-standard.
I notice this by reading the syllabi of the courses and do something about before I even take them.
For instance, I want to become a Software Engineer. There's a course called Software Architecture. What do I do? I buy a book (or books) before I even take the class, let's say, Clean Code. I read it top to bottom; make markings on it, apply what I've learned in the code I've written in, create at least one paper on a specific chapter, and a PowerPoint presentation based on that paper, and create a video (not me in the video) explainer about what I've learned using the PowerPoint.
So, basically, I can do that even if I'm done with the course and done well, especially if I feel the course wasn't that great. You wouldn't have to do all that if the class was really challenging.
There are universities that are really demanding and require a lot more hours to study from students.
Having said all that, I never rely on curriculum and professors to learn 100%. That's on me and what interests me.
This skill mostly comes from experience: by writing a lot of code, making mistakes and learning from what worked well and what didn't work.
However, you can speed up this process by learning and absorbing other peoples experience. There are some books on the topic: classics such as Clean Code and Refactoring and its also good to at least have heard about Design Patterns. Note that these books are dated and some practices have changed.
The best, most up to date, best practices you get from following blogs, conference talks, and looking at questions and answers here and on stackoverflow.
Dont have fav book per say. Last book i rly liked was Clean Code.
Yes. Lets dive in and do a code review:
1) getOrder() is reading from the console line, parsing and intepreting the string, checking it's a valid input, splitting that input into individual parts of the order, and performing a ton of logic trying to break down an order into a meal.
- As a reviewer, one big thing I look at when reviewing applicants is if they know their SOLID basics, and this one is a huge violation of the SRP (Single Responsibility Principle). You need to start thinking about splitting apart this massive method into separate classes, each with their own sphere of responsibility, and refacting your code to split apart those responsibilities.
- For example, you'd absolutely want a Reader class that is repsonsible for taking the console input, and a InputValidator class which can be responsible for checking that the input string is valid, some logic classes for handling the meal and sides etc.
2) You're using alot of comments. This is a somewhat controversial topic but it's something I see alot of from juniors and fresh uni graduates. In general, a comment (especially one describing a block of code) is a really good sign that you have a chunk of code worthy of its own function. A well named function describes exactly what it's doing, and is alot more readable than a chunk in a long drawn out method.
E.g: //Check if there were any faulty order IDs : This seems like an excellent chunk of code we can extract to a private method called CheckFaultyOrderIds()
Comments are also a sign of hacky smells. If you need to be explaining what a line of code is doing, it's either doing too much, it belongs to a class / method that isn't well named that describes its context, or it's being used to describe away some weird functionality. Your declaration of the orderIds and the proceeding 8 lines of instantiation logic which also contains 4 comments is a good example of how you're using comments as a crutch.
3) GetOrder contains MANY points of potential exit (lots of places are using return). Aside from an initial escape condition which should ideally be performed on some state of the input object(s) (such as when its null or empty etc), you generally want to try and return valid state only once.
- e.g: all the times you're checking Order.Meal and returning a string.
3) You need to rethink your class object structure and inheritance. There's lots of room of improvement here. I'll pose some questions here to set you on the right path, have a think about these and refactor from there:
- Why is Order a struct? What benefit does it being a struct provide? Are you sure it shouldn't be a class?
- Why are main, side, drink, dessert and water key value pairs? If they're all of the same type, perhaps they share a common interface. Is Water not a drink?
- You've got a constructor for Order, but it's not doing much that a default construtor couldn't. Is it really necessary?
- Does an order really contain both a meal and all the parts that consitute that meal? Shouldn't Drink, Side, etc all be part of the meal?
- What functionality does Order really serve if it just contains a Meal?
- Perhaps Order should be more concerned with figuring out what was passed in from the input, and Meal should be concerned with the parts of the meal.
- SetNone() based off its comment makes a meal invalid. An instance of an invalid class object shouldn't be be instantiated in the first place.
4) MenuSystem is a very confusing class. You're passing in a meal object, but instantiating mains, sides etc. based off a switch of some meal "types". If it's supposed to be for providing the customer with the menu options, then there's surely a better way to do it than this. If it's for creating an order, then why are we reading from the input? I'm really not sure whats supposed to be happening in this class or its methods.
I'm going to be perfectly blunt here with you mate; You may know how to write lines of code that compile, but there's a long journey ahead in making it readable an maintainable. Right now, you're missing some clear fundementals on object oriented design and SOLID. I'd HIGHLY recommend that before you write another line of code, you drop what you doing and do some theory; Pick up a copy of Clean Code by Uncle Bob, treat it like your bible, and do some courses online on object oriented design.
Good luck!
I can't recommend this book enough. https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
I had the same problem. What I can suggest is that you take a look at the Clean Code Book, it is a really good book and it challenges the way you look at code. It really helped me a lot. It will not make you perfect but it will speed up the process of you learning to write good code.
Sure! As a senior developer, these are books I think every software developer should read and keep a copy of on their desk or desktop:
- Clean Code (https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882)
- Code Complete (https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670)
- Design Patterns (https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612)
- Patterns of Enterprise Application Architecture (https://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420)
- Pragmatic Programmer (https://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X)
- Refactoring (https://www.amazon.com/Refactoring-Improving-Existing-Addison-Wesley-Signature/dp/0134757599)
You will notice that most of these books are written by the same group of people, who have been saying the same thing for many decades, probably since before you owned a computer. Yet the words they say still hold true to this day. I Think the wisdom held in these books is far more valuable today than when they were written.
Blog posts will teach you how to program, these books will teach you how to think like a programmer.
Aside from these, more book recommendations will depend on specific areas of interest.
This book has a good explanation on how to write good code:
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Another good one is this:
For general coding practices, I suggest Clean Code
and Head First Design Patterns volume 2
For Python programming, I don't suggest any books. I like a few YouTube channels, but the best method is trial and error. What I mean is, decide on a project to make (something small) and make it. You'll probably need to Google and research every step, but you'll learn more in the process than any book would be able to teach you.
Youtube channels I like for entry level Python: 1 2
Edit: formatting
>mas nao encontrei nada que conseguisse perceber
Esta é a parte em que tens de pausar em vez de tentar avançar em frente. Tens lacunas no teu conhecimento que tens de resolver antes de continuares. Isto requer analisares o que não percebeste e tentar compreender que conhecimento te falta para aquilo fazer-te sentido.
Isto é algo que acaba por acontecer senda do "FAZER PROJECTOS!", um bordão comum aqui no burgo, e é por isso que deves primeiro compreender a linguagem do nariz à cauda antes de começares a fazer um projecto que seja. Depois disso é criar pequenos exercícios, com um único propósito (e.g., uma única função) e fazê-los bem. Depois múltiplas funções para um propósito, múltiplos propósitos, etc.. Basicamente construir a casa pelas fundações em vez de querer logo meter o telhado, conforme Mateus 7, 24:27.
Quando tiveres isto resolvido e tiveres as bases bem firmes, podes dar uma olhada na santíssima trindade (por esta ordem).
https://martinfowler.com/books/refactoring.html
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670
Regardless of how bad it is, you will learn valuable things. If anything, you'll learn what NOT to do! Jeje
I recently transitioned to a SW Engineer position, after a long path from customer support to QA to SDET to SW Eng. I can recommend one thing, unprompted, is Clean Code because it is something I wish had been aware of when I first started. Specifically https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 (use your favorite book retailer)
Try to learn & apply good coding principles, regardless of how shitty the spaghetti may be. You will thank yourself down the road.
We’re learning about this now in the software engineering class I’m taking, the professor gave us 2 good books for your case: clean code by Robert C Martin and clean architecture by Robert c Martin and as others said, UML and figma are big for this topic as well
I head that Clean Code is really good for programming.
And Code Complete is for more advanced stuff.
Both of these books were recommended by Code Monkey in his 7 Steps to become a Game Developer video, I also heard of them being useful outside of game development.
You might already heard of that one but the book "Clean Code" comes to mind
https://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
It's one of the programmers bibles
https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Read (Uncle Bob's Clean Code)[https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882], it's applicable to any software engineering work
"Clean code" [1] refers to removing technical debt and making the code easier to read and modify by other developers.
[1] https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
For clean code here is amazon link
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
A lot of good advice about SOLID in these comments. There is another aspect of OOP that you need to understand to reach the next level. One of the big issues pointed at by functional programmers is the "monkey banana jungle" problem. The gist is that you ask an OOP program for a banana and get the gorilla holding the banana along with the whole jungle. This problem speaks to coupling. The tighter you couple your classes and code, the more brittle and difficult it will be to maintain.
One of the best pieces of advice I ever got was to "favor composition over inheritance." You don't need to eliminate inheritance, but realize that one object inheriting from another is the strongest form of coupling in programming. A person changing the base class can break so many other parts of the code because of inheritance chains. Learn about ways to compose objects and avoid coupling your code by inheriting from base objects. Sometimes, inheritance is the best solution, but this is rare.
Next, learn about inversion of control. Most people think about dependency injection when you talk about this concept, but it is more than that. In fact, sometimes dependency injection can lead to stronger coupling if you aren't careful. IOC means that rather than relying on concrete classes, you rely on abstractions like interfaces or abstract classes. Another component of IOC is not knowing too much about the object that you are interacting with. Code conforming to proper IOC will avoid things like
function coolVehicle(IVehicleWithWindows vehicle) { foreach(window in vehicle.getWindows()) { if(window.isDriverSideWindow) continue;
window.lower(); } }
This code violates a lot of SOLID and IOC even though we used an interface in the method. A better abstraction would be to move coolVehilce to the vehicle interface. That way the vehicle can implement its own version and cool the car. Some may want to use AC, others windows maybe others are water-cooled. The point is that by changing who controls the methods, you get less coupling and better code.
A few really good books for learning more about these principles.
Clean Code by Robert C Martin love it or hate it, this is a ubiquitous book. I recommend it.
Design Patterns by the Gang of Four probably my favorite book because it is the one that opened my mind up to new ways do OOP. The examples are in Java, but the book still applies to modern OOP.
Clean Architecture by Robert C Martin another Uncle Bob book. This one is more advanced and talks about bigger concerns like module design and orthogonal or onion architecture. Very good read.
Implementing Domain Driven Design this is a really good concept to understand. However, as a self-taught dev myself, it was a more difficult read. DDD is a really good concept to understand even if you don't use it. It is overkill for most projects, however, things like value objects and anti-corruption layers will help you avoid "big balls of mud".
Clean Code is a good one to read.
| Item | Current | Lowest | Reviews |
|---|---|---|---|
| Clean Code: A Handbook of Agile Software Craftsma… | - | - | 4.6/5.0 |
^Item&nbsp;Info | Bot&nbsp;Info | Trigger
Recognize SOLID principles as you code. https://youtu.be/UQqY3_6Epbg more videos by that author on the other principles in JS.
Use quality tools (TypeScript, Eslint, sonarqube, etc).
Read Clean Code by Robert Martin https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=nodl_ and skip all the super specific Java stuff like Java docs and testing.
Ask for code reviews from different people. Review your peers code. Surprisingly reviewing others code has been the most valuable.
| Item | Current | Lowest | Reviews |
|---|---|---|---|
| Clean Code: A Handbook of Agile Software Craftsma… | - | - | 4.6/5.0 |
^Item&nbsp;Info | Bot&nbsp;Info | Trigger
| Item | Current | Lowest | Reviews |
|---|---|---|---|
| Clean Code: A Handbook of Agile Software Craftsma… | - | - | 4.6/5.0 |
^Item&nbsp;Info | Bot&nbsp;Info | Trigger
I recommend you read clean code by Robert C.Martin
Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin) (Robert C. Martin Series) https://www.amazon.co.uk/dp/0132350882/ref=cm_sw_r_apan_glt_fabc_7W4A4X405N5YEJ63Y1WE
I find the most impactful book for new developers is Robert Martin's Clean Code. It can vastly improve the quality of code you write.
As you get more experience I would suggest another book by Robert Martin, Clean Architecture.
Read Clean Code book ?
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
I have to disagree with this.
Understanding renders is important, but also (to some degree) falls into premature optimization. Don't worry about it for now. Learn the fundamentals, and as you encounter issues with performance you will learn to troubleshoot and remove excess renders.
With rare exceptions, comments should not be used to explain...anything.
Good code is self documenting. If what a function is doing isn't clear, that should be broken out into more functions, each of which is clear on what it's doing.
Why are we writing comments about testing? Either write a test or don't.
The two directions I would put are..
1) Make sure you are using a linter, it will enforce best practices and save you a LOT of headache.
2) Read this --> https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
It talks - in more clarity and detail than anyone on reddit is going to give you - on how to organize code, write re-usable components/functions, and everything else that will fundamentally improve your skills.
Ah ok, apologies! In that case, maybe these two would be helpful, I haven’t read either but they appear to be highly rated:
In general, clean code is really important, especially when coding professionally. https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
This is best explained in Clean Code by Robert C. Martin (https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882). I recommend the read.
Basically, the problem with commenting is not when you write code for the first time but much later when the code is updated.
Let's say someone writes a whole block of comment about the goal of the class, what is the business logic, etc... Overtime the logic changes as the business changes. Some methods will be pruned, others will be extended. Very quickly, you will have this huge block of code explaining something that is not relevant anymore. Oh and why isn't anybody deleting this monster or updating it you ask? Because typically besides the first coder, most of the people aftwerwards will be changing the code to apply very small fixes. They don't know the whole logic (actually this is how good code actually works, you don't need to know everything to update it), there was however a crash yesterday because of a small bug and this needs to be fixed quicky.
Same goes with one lines. Before you know it, you have tons of one liners spread all over the place and nobody knows what they mean anymore. They are some relics of an era past gone...
By the way Robert C. Martin advises against docstrings comments for enterprise code. Open-sourcing is another story.
> Does anyone here struggle to remember the codes?
We're professional Googlers — no, really, we are. The volume of Google searches we perform varies throughout our careers, but the truth is that's what we do.
> I mean what is the proper way that I should use in order to learn ROR fast and more efficient?
You can pick two of these: fast, efficient, and well. You can learn it efficiently and well, but it'll take time. You can learn it fast and efficiently, but you won't learn it well. You can learn it fast and well, but it won't be efficient.
If your overarching goal is to create something great, it's going to take time.
Rails specifically contains a lot of magic — these are convenience features. They're what makes Rails... Rails. It's easy to shoot yourself in the foot with Rails because it gives you so many ways to do so many different things: there's often 10 ways to do something, and 9 of those aren't the "best" for whatever reason, but they all produce the same result (and varying bugs, performance implications, and "features").
> Where should I start? I need a very good and beginner friendly course.
It'd be a good idea to pick up Ruby basics. https://learnxinyminutes.com/docs/ruby/ and that's assuming you already know basic HTML/CSS.
Once you have the syntax down, go read https://www.manning.com/books/the-well-grounded-rubyist — this will lay a good foundation for what you're about to go through.
Once you're there, head to https://www.railstutorial.org/ and do the course in its entirety.
After you've completed Rails Tutorial, pick up Uncle Bob's Clean Code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 read and apply it.
I'd recommend using RubyMine as an IDE. It'll nudge you in the right direction as you write code, and its "Go to implementation" feature is as vital to me now in writing code as it was when I was asking the same questions you are many years ago.
After that, you should be able to be making contributions to production.
Of course, there are shorter routes than this. But if you want a means to be proficient with a good foundation, this is what I would recommend. I wish I would have done this instead of fumbling around for years, pulling my hair out.
You have a road ahead of you, and I wish you luck. Writing software is a weird mix of creativity, logic trees, craftsmanship, and brute force. It's almost as exhausting as it is rewarding — figure 49/51. Thankfully, that 51% means there are better odds that we will be happier at the end of the day. :)
Clean Code by Uncle Bob can help finding bad habits and shows how to correct them: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
He also has a lot of talks on YouTube, just look it up.
It seems like you are looking to learn a bunch of different separate things so I'll give a bunch of recommendations.
Functional programming: The best way to really learn functional programming is to learn Haskell and then use it to write a bunch of programs. I recommend https://adventofcode.com as a way to give you a list of challenges to solve with Haskell. Haskell really forces a functional programming mindset so using it gives you a much better understanding of functional programming.
Low level programming / C++: I would recommend picking up a book on C++. I'm not sure what the latest / best one is as the one I used is very outdated. I would make a special recommendation that you look into how to write C++ extensions for Python. That allows you to mix native code with your Python to get performance when you need it.
Improved Python Programming: I would make three distinct recommendation. First, I would recommend reading through the Google style guide: https://google.github.io/styleguide/pyguide.html. Second, you should look into Python type hinting (mypy). Third, you might https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 to be a useful book.
I watched a couple of hours of a conference done by Uncle Bob (Robert C. Martin). Here's the relative book: Clean Code
I've yet to buy and read the book myself, but I definitely plan to in the near future. His talks were enlightening and entertaining. I haven't been learning for a year yet, and a lot went over my head but I can imagine having this book on-hand for the years to come being a huge benefit.
I feel like I improved the most after reading clean code. It really changed the way I think about writing software. https://www.amazon.com/dp/0132350882/ref=cm_sw_r_cp_apa_i_lPZ9FbXA5NBFK
Refactoring: Improving the Design of Existing Code
Not only does it have practical advice on how to refactor but it also covers the value of doing it and what clean code looks like. Martin Fowler is a god.
Clean Code: A Handbook of Agile Software Craftsmanship
Speaking of clean code, this book by Uncle Bob is another classic that I don't think you can go wrong with.
Wow... Your power of articulation stuns me...
I'd suggest to read this book: https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
I recommend reading Uncle Bob's Clean Code, it has good practices every programmer must know.
What you're looking for is Software Design/Architecture.
Forget UML for now. It is a communication tool, won't teach you how to do things.
Some good resources I'd recommend you start with:
There are tons of stuff I could recommend but I thingkstarting with those 2 will give you great ROI.
Don't worry if the languages in those books aren't the one you work with, focus on the concepts
First, I want to agree with the sentiment of this post completely. As a beginner, with little context on how to accomplish something, being told to just go do it anyway is frustrating.
The problem is, that's really the only answer. You can read all the books you want (and there are some _really_ good ones out there), but until you actually start building something with it, you won't get much out of the readings.
This is why most CS classes have you build things. They come up with the lame exercises for you to do to practice on. In classes, they have you implement a linked list, or binary tree. This is something that outside of college I've never had to do. Most languages these days already have a much more efficient and fully featured implementation of whatever data structure I need to use. But, building them gives you some experience on how they work, while giving you something to practice the skills you are learning (loops, pointers, references, memory management, data structures, etc.).
I know all too well the frustration of having to learn by doing. When I was coming up in my career and was doing junior admin type work, I always asked my seniors what I should read to get better. The answer was always "Go build something, break it, and learn how to fix it".
That answer SUCKED. I didn't have something I wanted to build, I just wanted to get better at my job, and wanted to read something to get that information. Turns out, there's no better teacher than experience.
So when someone asks "How do I get better after doing [insert introductory class here]?," all answers boil down to "Start using it."
If you need help finding problems to solve, that's where the recommendations of Hackerrank, Leetcode, etc. come from.
There are also code katas (https://github.com/gamontal/awesome-katas).
Since most tutorials are focused on how to DO something, I'd also recommend learning how to TEST something. Learning automated test frameworks and TDD are very helpful, especially when learning early on, because you get immediate feedback on a piece of code, instead of needing to wait for the whole thing to be done.
For books, once you get a bit of experience, Clean Code by Robert Martin and Refactoring by Martin Fowler are both solid resources on how to write and improve existing code.
Clean Code is one of the best books I’ve read on programming. I believe that every programmer should read this early on in their career.
For DDD, the go to book is Domain Driven Design. I feel that this book is a little lengthy and could be a little shorter, but it is the go to book for DDD. It’s dry at times but worth the read.
For less messy amazon links you can extract the part after "/dp/" in
and make it:
BEEP BOP
Plz send any recommendations via PM
Here's what I've got.
This guide is mainly based on the Entry Level Embedded Software Career Guide by u/hamtaroismyhomie.
Disclaimer: Similar to u/hamtaroismyhomie embedded guide this is based on my own experience. My background is a UK based graduate that undertook 4 distinct internships over my 3 years at university studying Electrical and Electronic Engineering. Two were full time summer internships with a mix of hardware and software. I graduated in the summer with a first class degree and have been working full time as an Electronics Engineer for 3 months in a small contracting company. The companies I have worked, applied and interviewed for have been smaller companies. If you want information on internships at somewhere like Tesla I can't directly help but this guide should be general enough.
Build Things
When you apply for a job, you will be up against people with that went to the same or better university as you, that have done the same or better courses as you and have the same or better grade than you. You need to show the employer why you are better than that person and this is how. Build things.
Building something shows the employer you have the skills required for job; enthusiastic about the field; can take initiative and be creative. Not so surprisingly all the things required to work on hardware can be shown by working on some hardware. You can bring what you have built to interviews, letting you control a part of the interview and talking about how good you are while sharing your experience of building. And the good news is building something in electronics in easier than ever. For around $30 you can order parts and a PCB.
Okay so how do I build something?
Step One: Think of an idea. It dosn't have to that original just something thing you think you can do that has a challenge to it. Interested in power systems? Create a maximum power point tracker for solar panel. Like music? Create an amp or a filter. Being enthusiastic about the project is the most important thing because that energy shows through in interviews.
Step Two: Build a prototype. Buy some parts and put it on a breadboard. There is so much info online on how to make electronics you can work out. Keep a log, which you can bring to the interview. This shows you log your work and ensures you don't forget why you did what.
Step Three: Create a PCB. If you have never done this on your own before it can be scary. However it's a skill any hardware engineer needs. It also super cheap these days. Download KiCad and follow Contextual Electronics's Getting to Blinky playlist to start.
Step Four: Order your PCB and Components. Check over it a lot before you do, post it on reddit for someone else to check. Then check it again. Then you can order from one of the many companies that specialize in cheap, small, low run PCB manufacturing. Check PCB Shopper. To get components check out Digikey, RS, Mouser, Farnell, Rapid etc.
Step Five: Build it. This is a chance to practice your soldering skills. Even though will be mostly designing, at some point you will need to add a bodge wire to fix an error. Be ready to face that is might not work. Everyone messes up PCBs, or designs. It happens, most electronics you see around will be go through many revisions.
Step Six: Show it off. Add it to your CV. Bring it to interviews. Talk about it. It will make you stand out and be remembered. If you have spare, give one to the interviewer.
This may sound like a lot of work and cost, and it is but from what I have experienced and what I have read and seen. This is the best way to show that you can do a hardware role.
Note: I have skipped over a lot of things. If someone is interested in learning more about the stages of developing hardware I am happy to expand on it but there is a lot of information out there.
Fundamentals
- Basic Electronics - Ohms Law, Capacitors, Inductors ,Transistors, Active components, Logic. This stuff is the bread and butter of electronics and will most likely be asked about. Having this knowledge allows the building of more complex systems.
- Practical Electronics - Pull up/down resistors, driving MOSFETS, protection circuits, Switching/Linear power supplies, Op Amps circuits. This stuff is what you might use everyday as a designer. It crosses over with the basics but the important thing is how to implement this stuff.
- Microcontrollers/Firmware - Most designs will have a microcontroller. You can not avoid not knowing how to program and use them. C/C++ is vital and so are different com protocols. Check out the embedded software guide linked at the start. You don't need to know it all yet but at least the basics.
- Datasheets - Around 80% of the design stage is reading datasheets. You need to learn how to read them quickly and get the information out of them. Miss something on the datasheet and your whole design is broken.
How do I build these skills?
- Basic Electronics - This is book learning stuff. Look into any text book and you will be able to get this information. I suggest Art of Electronics. It's the bible for practical electronics and skips all the unnecessary maths. You don't need the most recent edition.
- Practical Electronics - Art of Electronics is very good here as well. It teach you how to use things and provide useful circuits. Also Youtube is a good source of electronics info. Youtube is also good.
- Microcontrollers/Firmware - Buy an Arduino and make something. Copy some guides and work your way up. I would also suggest reading about writing Clean Code. The book is aimed at software devs following agile but I think writing clean code is very important and not done enough in electronics.
- Datasheets - This just takes practice. Go on Digikey and just look at different datasheets to get familiar. Building things is also a good method of getting better at reading datasheets.
Resources
Ben Eater - Logic and Breadboard Computers
EEVblog - Crazy Aussie dude (Big backlog to go through)
Great Scott - Cool projects and tutorials
Marco Rep - Whole load of random stuff, super interesting
MicroType Engineering - New channel but really interesting and detail stuff. Lots of good learning and real life examples of circuit design
The Signal Path - High end test gear teardowns
The Current Source - Electronics and stuff
w2aew who just does great explanations of different electronic concepts.
The Amp Hour - Hardware focused podcast.
Adafruit - Good guides and starting products
Sparkfun - Ditto
Hackday - Lots of articles about electronic projects. Can teach you a lot.
Interview Questions
What is static? What is volatile? How does an interrupt work? Basic circuits questions: Ohms law. Voltage Dividers. Series and Parallel Resistors. Compare and contrast I2C, UART, and SPI How does an ADC work? How about a DAC? How do you on a P Channel MOSFET with a microcontroller?
I hope this helps. I'm not the most experienced person in the world but I have gone though this recently. If you notice an error please let me know. If you want more info about a subject or have any questions, please ask away.
I thought Clean Code by Robert Martin was pretty good (https://www.amazon.ca/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882). Although, I've found that reading blog posts online have been much more beneficial when it comes to learning Computer Science topics (I highly recommend reading Martin Fowler's Blog - https://martinfowler.com/).
Proceeds to link to Clean Code: A Handbook of Agile Software Craftsmanship
If you want to learn procedural terrain then brackleys has a simple video.
If you want something more advanced then Sebastian Lague has the best series.
https://www.youtube.com/playlist?list=PLFt_AvWsXl0eBW2EiBtl_sxmDtSgZBxB3
If you want to skip procedural and just hand make everything (I suggest this as a start) then look at free assets on the asset store to get a understanding. Modeling in Blender is a whole seperate part of your learning experience. I would start with basic prototyping and would not make any assets yourself until you are happy with your prototype.
Just use unities basic objects coloured differently to start.
This brackleys tutorial can teach you basic terrain also.
Edit ohh and if you want an offline resource. The best book you can read to help organise your code is : Clean Code by Robert Martin.
https://www.amazon.com.au/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
I think you should check this book Clean Code
Yes, if youre concerned read the book clean code. https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Try amazon smile to donate to a charity of your choice automatically at no cost to you!
https://smile.amazon.com/dp/0132350882
^^^I'm ^^^a ^^^bot ^^^and ^^^this ^^^action ^^^was ^^^performed ^^^automatically.
Ia si invata algoritmica, o sa te ajute chiar daca nu o sa ajungi la co companie FAANG, te va ajuta sa scrii cod corect si eficient si o sa-ti structurezi mai usor ideile. Sunt cateva firme mai rasarite si in Romania care dau algoritmica la interviuri.
Niste exemple de probleme de la interviuri: https://leetcode.com/discuss/interview-question/398023/Microsoft-Online-Assessment-Questions , https://leetcode.com/discuss/interview-question/344650/Amazon-Online-Assessment-Questions, https://leetcode.com/discuss/interview-question/352460/Google-Online-Assessment-Questions .O sa gasesti majoritatea algoritmilor clasici implementati in C++ aici : https://cp-algorithms.com/ . Si pe codeforces o sa gasesti articole destul de bune: https://codeforces.com/blog/entry/43256 , poti sa participi si la concursuri dar daca vrei sa devii bun trebuie sa investesti mult timp in asta.
Dupa cum a zis dustbust_ Cormen e o buna referinta pentru analiza algoritmilor desi s-ar putea sa fie coplesitor la inceput .
Nu ti-ar strica sa citesti https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 ca sa inveti sa scrii cod mai bun, cand o sa lucrezi o sa trebuiasca sa scrii cod astfel incat sa fie cat mai usor de inteles de colegii tai, invata SQL si citeste si https://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557. Nu uita ca fiecare guru sau tech lead are impresia ca l-a facut masa geniu, ia cu un grain de salt ce zic, invata ideile de baza si adapteaza-le pentru situatii tale.
Ca programator o sa inveti tot restul vietii, e important sa-ti formezi la inceput o baza solida.
> Clean Code by Uncle Bob
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) draw.io 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.
Nice! It's a good start, although I can tell that you're a novice developer.
A handful of specific directions you could look into:
Double-down on ES6. It's not going anywhere.
letinstead ofvar, arrow functions wherever appropriate (NB, this is not everywhere).awaitandasyncare great if you have good reasons to use them.Testing. Learn you some test-driven development! In Javascript-land, a couple of good tools for this are Karma and Jasmine. The key here is to write the test before the code. This forces you into creating testable code, which, as it turns out, is generally more maintainable code.
I highly recommend reading Clean Code which goes into TDD and many other aspects of professional coding etiquette. It will also give you an idea of how to organize your source code (hint: the business logic probably shouldn't be all under the routes directory).
Consider coding your server in a different language than your client. This is purely to help you expand your horizons a bit beyond Javascript. I recommend Python 3, potentially with Flask.
Find someone else to help with the project! This could essentially double your learning as you'll be forced to understand how someone else might approach a problem (which is often in a different way than you might choose).
Finally, you might consider the CS degree route. I didn't finish my CS degree (although I did have a diploma in computer programming from a community college), and I think it probably pushed my career back a few years. It's certainly doable without the degree, but it's essentially concentrated learning that's well-recognized and can set you up with an initial network for your career. If you go this route, try to do it cheaply; consider community college first and transferring credits, or going to a cheaper state school (unless you can get into e.g. MIT, Stanford, or Waterloo, i.e. a place well recognized by name for CS).
People here will (and so far a few have) say that the CS degree is absolutely necessary; this is because most of them are CS students. I don't think it's necessary, but it helps.
In relation with your third point, I thinks it's very important to make a good readable and understandable code. Clean Code (https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) can guide you through writing better code.
Also reading code from others is also a great source of improvement. This goes from other people's github projects to well-known libraries documentation.
Hi, always nice seeing new people getting into programming. I'm sure you'll find that by necessity this is an extremely helpful and sharing community.
If you are interested in reading any form of material regarding programming I would start with recommending Clean Code by Robert C. Martin. It basically tells you how to make your code more readable for others.
When you have gotten the basics down I would also recommend you read Game Programming Patterns by Robert Nystrom. This one you can read for free on the web and is simply about various patterns used in programming and what they are good for.
I'm from Sweden and currently study game programming. I'll be happy to try and answer any question you want to throw at me. :)
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.
Airbnb's JavaScript Style Guide is extremely thorough and in-depth and up-to-date if you need a reference.
https://github.com/airbnb/javascript
Purchasing this book is a must I hear all the time from industry professionals. You can probably find a PDF of it online as well.
Clean Code: A Handbook of Agile Software Craftsmanship by Robert C. Martin
Buy your team a copy of Clean Code, you won’t regret it!
Read and apply everything from Clean Code, really.
Besides the language I would read about software architecture design modelling and tools.
UML: class diagrams, activity diagrams, sequence diagrams. Specifically in regard to class diagrams look at relationships (Composition, aggregation, inheritance). These relationships are the cornerstone of what object oriented software is.
Also take a look at common design patterns. You will likely here terms like 'factory', 'singleton', etc, often.
Read a book like Clean Code. Code readability and maintainable are key. If your company does frequent peer reviews most of your peers issues with your code will be about the look and feel of the code, rather than actual issues with it.
Lastly, A good practice for improving some soft skills would be to go into open source repositories and dig through the code. Start at main and find out how the open source software does what it does. This skill is invaluable when moving onto new projects.
The most important things for making code readable, in my opinion are:
Use meaningful names for variables, functions, classes, methods, etc. The name of a variable should tell the user what information the variable contains.
mis a poor name.monthis better, but is somewhat ambiguous, since you don't know if it holds the name of the month or the number of the month.monthNameormonthNumberare way better choices.Use enums or constants instead of [magic numbers](https://en.wikipedia.org/wiki/Magic_number_(programming\)).
For instance, compare the readability of:
if ( dow == 2 )
with
if ( dayOfTheWeek == TUESDAY )
Lay out your code so that it looks pretty. Be consistent with indenting and spacing.
Split your code into bite-sized chunks by pulling out bits into separate subroutines. Even if you're only going to use it once, putting code in a separate subroutine means you get to give it a name, which will describe what it does, and the original code then becomes shorter, making it easier to understand.
Someone else mentioned this in another comment, and I second it - read this book.
Two words: Clean Code
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Just a good book that showcases a proper way to design your code structure.
A couple days late, but this book is a must-read on this topic: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1522625510&sr=8-1&keywords=clean+code
I've heard ppl recommending this https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
There are no good resources for Apex development IF YOU CONSIDER CODE QUALITY TO BE IMPORTANT.
Which means, there are NO GOOD RESOURCES FOR APEX DEVELOPMENT.
What worked for me: 1. Learn Java. SAMs Teach Yourself Java in 24 Hours is good for this.
Learn Object Oriented Programming. SAMs Teach Yourself OOP in 21 Days is good for this.
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): http://javarevisited.blogspot.com/2014/08/top-5-books-to-learn-unit-testing-junit-tdd-Java-programmers.html
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.
Learn about design patterns: https://www.tutorialspoint.com/design_pattern/index.htm
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.
Learn about clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Learn to use version control (e.g. git). Atlassian's tutorial will probably teach you more than you need to know: https://www.atlassian.com/git/tutorials
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.
I would go with the "Clean" series by Bob Martin.
Clean Code: A Handbook of Agile Software Craftsmanship
Clean Architecture: A Craftsman's Guide to Software Structure and Design
The Clean Coder: A Code of Conduct for Professional Programmers
You will continue to feel that way. Unless you're way different than I am. I definitely feel that a lot. Trick is just to keep writing things!
If you really want to dig into the methodology of it (software engineering), then I highly suggest both Clean Code and Code Complete. For where you are right now, I wouldn't try to "cover-to-cover" them, if you do pick them up. Pick out chapters that sound interesting, or level appropriate, and read through those. Then, and this is the important part, try to write code that fits.
I find that the larger projects that I work on are the most interesting as well. There's no shame in re-implementing something that already exists, either. It's an important experience to see where and why great designers made certain choices.
Good luck, and keep it up!
The cliché is that "scientists" produce very bad code (even if it works correctly...)
Try reading this https://www.amazon.com/gp/product/0132350882/ to see if that applies to you too. :)
Look at the following books:
Working Effectively with Legacy Code (even if you are not working with legacy code, lots of good hints on modularity here)
Clean Code and The Pragmatic Programmer are the usual suggestions. Code Complete is a big tome of software development advice, easily the least dollars per kg I've paid for a book.
In your specific case there's really no way to know what features you want except for experience in the field. Things like saving and AI are not problems that can be solved simply by having modular and well tested code. They require fundamental things like a properly tracked state and API for the AI.
It falls under the general advice of property specifying your program before you start writing, this is emphasises in at least one of the above books. But there's specifications are diverse so nobody can teach you how to figure out everything you might want in your specs. Maybe this 4 part blog from the CEO of StackOverflow might be useful:
Some of what you are missing Design Patterns. There is no point in reinventing the wheel.
Clean Code. There can be an infinite way to write code. But there are some ways that are better than others. It isn't enough that your code compiles and works. This is an oversight that everyone can suffer from. Actually whomever has to maintain your code will suffer from.
https://en.wikipedia.org/wiki/Design_Patterns https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
It's hard to do justice to it in a FB comment, but the clarity of the code, the modularity, and simplicity of it, just quite a lot of stuff. Well written code just looks so much simpler. Functions are short and simple, rarely more than 10 lines with 2-4 parameters, rarely more than 4. Classes are short, rarely more than 1-2 screens worth of code. In general, good code keeps the "cognitive load" low. Unit tests are very thorough, and can also serve as a form of documentation.
I highly recommend the book Clean Code: A Handbook of Agile Software Craftsmanship. Its advice is language agnostic. The author also has a number of lectures on YouTube, although his speaking style is "interesting" and may not be to everyone's tastes :)
If you're not sure how good your unit tests are you can look at something like mutation testing to find out, although it's more of a personal thing I like - it's not that widely used.
Don't worry, knowing what you don't know gets you 95% of the way there :)
> This is due to lack of readability, inefficient code, and not using best practices.
Read these books, and you will learn most of what you need to know in order to write (clean | readable | effective | efficient | easy-to-maintain) code:
> I was under the impression that htmlspecialchars
Even so, why not phrase your question like that to begin with, rather than ask something you can find in the documentation? Part of getting help is asking the right question.
> I prefer to put an html comment containing the file's name into each included file that makes up the html template markup.
That's just not necessary with blade templates. Every blade template that calls an include has a full path to the include and what not.
> I don't yet have the Linux skills to be responsible for my own private server.
That's very fair, and sometimes doing this can actually lead to more problems than it solves, so I get that. However, what's stopping you from learning on your own right now? Servers for Hackers has an excellent series about this stuff.
On top of that, just find a different host. Plenty of hosts will let you run composer, so find a better one.
> We don't have tests. Nobody is going to pay me to make tests.
Bullshit. Tests are vital, especially if you deploy frequently. I suggest you give Clean Code a read. None of the applications I've taken over to maintain have had tests, but I just started adding them and eventually the business saw value from it. The way you win this battle is to write some tests for some known good cases, and when they ask you to edit code, let it fail and show them how tests can catch the problem. Regression tests are a must imo, and not enough developers realize they don't "need permission" to write tests. When you write software, part of doing that is testing it. There are no 'buts'. You just do it.
> There are better things I can do/learn/make with my free time
And now we see the real reason you don't want to write tests: you don't see the value in it. I can't convince you through a textual argument, but I sure as hell could show you if you let me poke around on your app for awhile.
> plain php logic has worked fine for the last 12 years
So this has been 100% bug free for 12 years? I'm doubting that.
> Trying to fudge this format into what I need honestly feels inferior
So here's another "did ya read the docs?" question, because they show other ways of adding validation. That said, after the experience of writing nearly 10 laravel production apps, I much prefer the string syntax because it's very quick and easy.
I have a strong feeling that several of your custom php validators are handled by laravel by default, and a lot of your mess will just disappear if you use something that's built to abstract that stuff away from you.
All of that said, to each their own. You're obviously entitled to your opinion, but know that you made your opinion based off what seems like inadequate amounts of research and poor assumptions.
Also, I PMed you last night offering to help you out, and you seemed to find time to respond to this, but not to that. That has me questioning if you truly wanted help in the first place.
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!
Buy the book and find out.
Seriously though it is highly recommended.
While not Python specific (it's in Java) this book is very good. Clean Code: A Handbook of Agile Software Craftsmanship
I really suggest you read Clean Code. It will change your life as an engineer.
Le meilleur moyen c'est de bosser avec des gens qui font du code "pro" et "propre". Peut être bosser sur un truc open source. Il y a le compte twitter my first PR (pour pull request) qui donne plein de pistes là dessus.
Une fois j'ai eu dans mon équipe un dev qui sortait de l'école, on codait tous façon "pro" dans l'équipe, il a très vite pris le pli et au bout d'un an il avait monté la marche. On l'a très bien vu quand il a du faire un passage de connaissances a un mec qui avait 10 ans d'xp mais qui était resté amateur. Il était bien meilleur que lui.
A lire pour commencer, il y a clean code et sourcemaking.com (oublie la partie UML, tout le monde s'en pète).
En plus ésotérique, il y a le C2 wiki.
Pour aller plus loin, suivre et lire et dévorer les écrits de : kent beck, michael feathers, martin fowler et robert martin.
Si tu veux/peux mettre un peu de sous, il y a le site clean coders de robert martin.
Je pense que tout se trouve sur libgen et torrent si tu veux pas payer.
Après, une fois que t'as un peu compris les bases, c'est de la pratique et de l'expérience. Avec des règles comme :
- Si tu peux regarder une méthode et tout comprendre en moins de 3 min, c'est maintenable.
- Si tu sens l'envie de mettre des commentaires pour expliquer ce qu'il se passe, essaie de refactorer à la place.
- Si tu écris pour la 3eme fois un truc quasi identique, refactore à la place
Terminei de ler o Clean Code e o The Choose Yourself Guide To Wealth, agora comecei a ler o The Go Programming Language. Queria ler alguma aventura, mas pra ser sincero dei uma procurada por cima e nenhum título atual realmente me chamou a atenção.
My go-to recommendation is the updated version of the book I learned to program from. It is free.
> placed first in a couple hackathons
Oh, so they already know how to program and have been doing it a bunch? In that case, Bob Martin's writings are probably what you'd want for building habits that will make you more effective. Or this one is free and is a more hands-on guide to some of the same habits.
I know right?! I was like that as well, until I had been enlightened.
Here is my new bible: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
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.
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. http://www.jamesshore.com/Blog/Red-Green-Refactor.html
Though its not JS specific, anything by Sandi Metz is awesome, highly recommend her 99 Bottles book. https://www.sandimetz.com/99bottles
Uncle Bob's Clean code is a great resource as well. https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
If you are a person who tries his best to keep his code tidy and readable, I strongly recommend reading this book: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
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: https://en.wikipedia.org/wiki/Single_responsibility_principle
The book is really well written and has helped me a lot in making my code readable (atleast i hope so :) ).
Not OP but i can try to answer.
The key here is that OP introduced the extract method tooling. What that does is that it allows you take a block of code and have your IDE move it to a method. That's useful for moving large chunks of code out of a single gigantic method and into smaller methods. In general smaller methods are easier to read and debug, large methods are a code smell (I'll explain that next).
A code smell is basically an indication that something is wrong. The people that came up with the term tried likening it to opening your refrigerator door and smelling something bad. You know some food in there is rotten, but until you start examining everything you won't know which one is bad. A Code smell is similar. It's a sense you develop when you see certain patterns and know the way the code was written is bad and will lead to problems. For example, large functions or methods are a code smell. Variable names with numbers (int count, int count2) are code smell. It's something you develop after a while.
While it does looks weird, it's accepted terminology. People wills say "keep your code DRY" for example. Just think of dry as a short cut for "remove duplication"
In terms of refactoring code (and general best practices) these two books are great:
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;
- Clean Code - This book is going to go through a lot of concepts and keeping your code maintainable and is a very short read.
- 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.'
- 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.
- 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.
With regards to the actual naming of controllers, and the methods within, I'll paste a comment I made on another post:
Your controllers should only ever have one of the seven REST actions: index, show, create, store, edit, update, delete
If you do this for awhile I think you'll find that it produces cleaner and more maintainable code.
So, in this case, in your articles controller just have a method called index which will return all the articles for you. You are free to do the sorting on the controller and then return it if you like, or you can still sort it in the JS.
For reference here's a Taylor Otwell tweet about using only the seven REST verbs: https://twitter.com/taylorotwell/status/735999833102680065?lang=en
And here's a summary of the same point that DHH made in an interview: http://jeromedalbert.com/how-dhh-organizes-his-rails-controllers/
To address the general point: As others have stated, controllers are indeed meant to be used for multiple things. Typically up to the seven things that I listed above, but you can utilize as many or as few of those methods as needed.
Beyond that, it is almost never a good idea to abbreviate function or class names (as /u/Towerful has also stated). If you're interested and have the time and money, I'd recommend that you pickup a copy of Clean Code for some general coding principles.
Also, I think you'd get tremendous benefit from reading the Laravel documentation and/or getting a Laracasts subscription.
Checking it out...
First thing I did is went straight to tests. +1 for having tests!!! People truly don't get how important it is. I think a package that you may find useful for your tests is Faker...it helps to "generate" data for your tests without distracting the tests with too many literals. Check it out: https://github.com/fzaninotto/Faker
I would suggest removing comments. Comments rot, and looking at most of them, they don't add any value. Your code should be self-documenting. This means to have expressive names and syntax that eliminate the need for comments. Well-written code, and tests, that should be all the documentation you need :) I highly suggest reading this book which harps on this topic a lot, it may be one of the most respected books on software: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
You used types!!! Awesome!!!
I saw some nested if-statements...to me, I usually pull this out into a private function (see self-documenting code comment above).
In your Row.php class (and some other places), you have a "new" declaration. "New is glue," I highly suggest looking into a DI framework, it will make your code more testable and easier to maintain. I have some experience with this one: http://php-di.org/
I think your code is pretty good. Short functions, use of types and namespaces, testing, etc. My suggestions (if you implement them) shouldn't be too difficult.
Sure, not sure if you saw my edit but sites like CodingBat and Exercism are great resources.
Others would be just technical books and tutorials. For example read the following books:
There are a ton of great tutorials on Pluralsight.
You're not going to find any books specifically on problem solving, but reading through technical books and getting better at specific technologies then applying them is the way to get better at problem solving. I guess what I'm saying is that you're not likely to find a book that says "do this to get better at solving problems", you'll find books that give you technical ideas and when you go use them and run into problems that's how you grow.
I have been a software engineer for about a year. We use Test Driven Development where I work, and I have found that it really helps me think through the requirements and make decisions about what the software should do one step at a time. I definitely prefer this method to just "feeling it out" like some of the intuitives do.
I have also found it incredibly useful to get familiar with good programming practices and patterns and would recommend stocking up on books and maybe reading them with another person or two for discussion. Clean Code and Agile Principles, Patters, and Practices have been very useful for me. Once you start to get the general patterns down, designing something from scratch isn't such a mind explosion, because you have a general idea of how things should be designed and what "good" software looks like.
If possible, avoid it. C# already provides you with enough clarity
public Variable {get;set;} private variable;
public SampleMethod(variable){ this.variable=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: http://stackoverflow.com/questions/450238/to-underscore-or-to-not-to-underscore-that-is-the-question/17937309#17937309
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.
Is it this one I should buy?
Get a copy of clean code.
I work on proprietary software, my employer would not appreciate me sharing the code...
Yeah no problem. If you don't mind reading textbooks, I recommend you read Clean Code. It goes over things like this, including commenting.
Hmm...
Books on algorithms and data structures are vital to becoming a decent programmer plus they are universal. This is generally covered in universities pretty well but if you aren't studying IT then you will need to do it by yourself. Big emphasis on need - difference between sorta programmer that knows a syntax and can make an app somehow vs a programmer that actually understands what he is doing and what's to expect performance wise is immeasurable.
There's quite a lot of guides on how to write readable and clean code too. An interesting book on this might be this one.
Apart from that you will just bump into existing projects and frameworks as you decide to study specific programming topics. For example web development + Python will eventually lead you to Django. And to use Django you need to understand MVC patterns and OOP.
Wanting to make games will causes you to understand concepts of advanced optimization (just try for example rendering a whole map inside a 2D RTS game instead of only what can be seen and then you get to see drops to sub 5 fps on a $1000 rig :D), there are also some interesting pathfinding algorithms. Easiest one being Dijkstra but in games you generally use A*. And pathfinding for example is a HUGE field, there are whole PhD works on this!
If you deal with some advanced objected oriented programming (eg. if you for example decide to make your own implementations of binary trees/hash maps, how to make objects comparable etc) then you will eventually stumble upon concepts of metaprogramming, templates and reflections.
Sooner or later every programmer runs into parallel code too (and then you realize that you knew nothing and will want to hide under the blanket to never leave it again as parallel computing is a scary field once you first see what it actually encompasses ;)).
Deciding to work on OCR software will make you open physics books on optics and possibly even touch basics of machine learning (basics as to understand this particular topic properly you need university graduate level of mathematics).
But ye, the general rule is to just aim for SOMETHING and read on these topics. It also helps A LOT to look at other people projects on github in the category that you want to improve so you can see how they work.
The smaller the better. From a development point of view there is a lot of god materials on writing clean code that is easy to read, work with and maintain. (https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1468632974&sr=8-1&keywords=clean+code)
I break everything into smaller functions. Each function gets it's own file. The vast majority of my functions and scripts fit on one screen (once you get past the help and parameters). You build a library of functions that are very easy to find. Because the name of the file is the name of the function, I can look at a tree view of the folder and see all of my functions and go right to it.
When you use source control, you have all the changes and edits very cleanly defined. All the comments are more localized to that file. If you have pester tests, it is easy to pair them up and know you have coverage. If you need to track down a old version of a function, it stands on its own. You can much easier tell the last time that piece of code was changed. (even if you are looking at filesystem based backups.
These functions become reusable as modules and only have to exist once. If you copy the same functions over and over into other scripts, then you also copy bugs around. If you fix something, how do you know you fixed it everywhere it was used? If it is a standalone function in a module, improvements to that one file benefit every script that uses it (This is where you benefit from automated tests).
When you have small functions, your nesting is less deep. Your variables are also tighter in scope. This means you can use very basic simple variable names. You can call that thing $user and get away with it. Those giant scripts are full of $userName $tempUser $userObject $user2 $newUser $ADUser $userList and the longer the script, the more creative you have to get. Also in smaller functions, you can see the initiation of all the variables are you using on the same screen that the code using it is on.
The monolithic file works great when you are just in the zone and laying out code. For those 2-6 hours, you have the whole script in your head. Scrolling around is not a big deal. But when you return to it, that mental map is gone. You have to scroll all over to see what is going on. Often you will see giant blobs of comments telling you to stop scrolling.
The smaller the better and each in their own files. However small your functions are, they are still too big. My functions are about 1/3 help, 1/3 parameters and 1/3 code. I'll stop ranting there. But you get my point.
This is true, and why I recommend folks read Clean Code when they're interested in writing better code.
Computer Science wouldn't have helped you there, they don't teach this kind of stuff.
You say you've been studying and it's helping a lot, how are you studying? Books? Courses?
For your kind of problem (code architecture and design, legacy code refactoring, etc), I don't think there's a shortcut. It's all about knowledge and (probably years of) experience. I can suggest some books that will definitely help you (you might have read some of them):
- Clean Code
- TDD by Example
- The Art of Unit Testing
- Refactoring
- Growing Object-Oriented Software, Guided by Tests
- Working Effectively with Legacy Code
- Domain-Driven Design *Patterns of Enterprise Application Architecture
Of course there are many others, but the list is already long enough :)
I think you're on the right path, practicing will definitely make your skills better.
I strongly suggest you to learn about common architectural patterns, like MVC, MVP, etc. and try to build to build something using them, as practice.
Testing and TDD specially would also improve your code design skills, so I recommend you spending some time practicing it.
Here's a list of books that I think will help you:
- Clean Code
- TDD by Example
- The Art of Unit Testing
- Refactoring
- Growing Object-Oriented Software, Guided by Tests
- Domain-Driven Design
- Patterns of Enterprise Application Architecture
I'm thinking about creating a course on code practices, design/architecture and testing and looking if there's demand for it. Would you be interested?
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.
I think I get it.
My concern is that the investment (time & effort) for you to get to "advanced intermediate" might be very big for someone that wants to write software non-professionally.
Nevertheless, if you're up to the challenge, here's a list a books that I think will give you solid foundations on the software part, which I think is more important for you than the hardware/linux side.
- Clean Code
- TDD by Example
- The Art of Unit Testing
- Refactoring
- Growing Object-Oriented Software, Guided by Tests
- Domain-Driven Design
- Patterns of Enterprise Application Architecture
I'm thinking about creating a course about coding practices, design/architecture and testing/TDD, for people who knows how to code but want to take their skills to the next level. I'm currently gauging for demand, would you be interested if such a course existed?
If you have no (or not much) professional coding experience - writing software that people actually uses, you are probably right about your current programming skills. AFAIK they don't teach this in college.
For you to start, I'd recommend some stuff that you could look into:
- OO design principles: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
- Uncle Bob's Clean Code
- Practice!! :)
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.
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
^ This book is a great start.
Stuff like this is quite frustrating actually.
You're declaring me a hopeless case? You're literally arguing that we should have comments in our code that reference individual people in the company and why we did things based on conversations we've had with them? Yeah, comments like this are 100% pollution and I would delete them without question the moment I saw them.
Comments in general are pollution though, yes. And it's not just me that thinks this - there's an entire section in the book literally called "Clean code" that talks about this exact thing: http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1449786605&sr=8-1&keywords=clean+code
Honestly, I'd love to know where your confidence comes from. I'm sure your code is messy if it requires comments all over the place. Mine generally just doesn't require them. Consider this:
Comments often go out of date. Often people go into the code, update something, then forget to update a comment. This leads to comments that are lies - this is more harmful than no comment at all
If you rely on comments instead of writing code that is self documenting, it encourages you to write messy code.
If you enforce a no comments rule, it forces you much more to have to write code that doesn't need comments. Code never goes out of date - if a method no longer does what it once did, you rename the method and viola! Up to date.
My code is generally far easier to read than the code most people write. I know this because I've spent years working on it, and I've pair programmed with some great people - learning things every step of the way.
You know, just because someone disagrees with you, doesn't make you right. It's quite obnoxious to declare me a "hopeless cause", especially when I've had the benefit of working with BOTH methods of working, which I guarantee you haven't.
I also guarantee I'm a much more experienced developer than you. Let's just call it a hunch.
Keep on trying though.
*Edit article for you to read: http://butunclebob.com/ArticleS.TimOttinger.ApologizeIncode
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..
> Laravel is used by so many students, that's why it has a big fan community, and like no professional projects.
So this is wrong, of course. I use Laravel PROFESSIONALLY, at work all the time. So do a lot of other agencies and businesses. I also know how to write proper PHP, so I'm not relying on Laravel magic simply because I don't know what I'm doing - I use Laravel because I've deliberately chosen it as the tool I want to use to save me from having to write a bunch of boilerplate code that I know how to write myself, but don't want to because it's time consuming
So please, stop with this stupid "It's a framework for students" argument.
> Patterns are the key of OO design.
Yeah no. That's not what patterns are, and not what they're for. As I said, you don't just implement a checklist of patterns and automatically have well designed software. Using the right patterns, in the right way, for the right reasons in the right situations is just one key to good OO design.
"I used the template method pattern, therefore I have good OO design" is not how patterns work. At all. Not even close, actually.
> because of the clean component architecture it's using It's NOT clean. Please stop spreading this false information about Joomla's component system.
> You're the one pretending that wordpress is the best for everything.
No, not at all. You are not even reading my posts. I HATE Wordpress. It's shit. I rant about Wordpress every chance I get. But you know what's worse than Wordpress in all situations? Joomla.
> Readable code, with good comments, is the most important.
Nope. Good code should rely very little on comments. Comments can become out of sync with the code, and tell incorrect things about the code. This is worse than no comments at all.
You really ought to read Clean Code by Robert Martin
And btw, Joomla is not readable code. At all.
From your question, it is not really clear, what you exactly mean, when you are asking »How to learn python deeper«. The first thing, which came to my mind is just, what you wrote: reading such books as »Fluent python« or »Effective python« And as you wrote, they go to the grass roots and get you a glimpse "behind the scenes" - not as deep as »ruby under a microscope«, but let's say behind the surface.
Then you change the focus, asking, whether it makes sense to learn other languages, such as C++ and Java in order to get a deeper understanding of python.
There are two sides of the story: If you start learning more languages, for the sake of the example say Smalltalk and Haskell, you learn two paradigms (OOP and functional programming) which have nothing to do with python itself - since they are paradigms.
On the other hand the more you explore the different programming paradigms (which are both supported to some degree in python), you are able to use the possibilities of python, understand how python supports this paradigms and indeed deepen your knowledege of python (somehow).
But I think, there is no direct correlation between learning one language to get better at another; what you really deepen is your understanding on (abstract) concepts like »Objects« or »Higher Order Functions« and enhance your conceptual toolbelt. Or if you think about the mechanism behind Ruby's »Method Missing« - If you got that, you find, that Python supports getattr, which is very similar. If you stubled on that concept learning Ruby and didn't know that Python supported it, you could start googling for siilarities and would have learned something in Python induced by exeriencing other languages.
»I have no background in CS« Neither do I. But what helped me a lot, was reading different general Books like:
If you want to learn cross languages, I would recommend reading
Para aprender a programar de una forma professional recomiendo dos libros del mismo autor:
Clean Code -> habla de como escribir codigo limpio, fácil de entender y sobre todo facil de editar/cambiar (Que es lo mas escencial si quieres implementar cambios pedidos por clientes rapidamente)
The Clean Coder -> Este no es TAN importante, basicamente habla de como comportarse dentro de el trabajo, por ejemplo, cuando y como decir que NO, como comportarse como individuo dentro de un equipo, etc.
Ambos han sido los mejores libros que he leido hasta ahora de programacion. Creo que el autor tiene background en c# o java y los ejemplos son en ese idioma, pero son facil de aplicar a otros lenguages de programación.
De las otras preguntas pues no te puedo ayudar mucho, pero te puedo dar una cuantas recomendaciones en general. Usa mucho paginas como StackOverflow y sobre TODO, UNIT TEST, UNIT TEST y mas UNIT TEST :D
First, don't take too much hay on your pitchfork. If you want to be proficient in everything you've listed, it would take 7+ years. Unless you're a prodigy, but then you wouldn't need a mentor ey :-)?
My suggestion is reading some books on the subjects. Something to start with: - http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 - http://www.amazon.com/Test-Driven-Acceptance-Java-Developers/dp/1932394850/ref=sr_1_5?s=books&ie=UTF8&qid=1444376098&sr=1-5&keywords=tdd+in+action
Also take a look on http://codereview.stackexchange.com/
Feel free to PM me with concise! & to the point! questions about: java/groovy/algorithms/data structures/best design practices/clean code.
Read this :
http://www.amazon.in/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Learn about the Single responsiblity principle.
And don't worry so much about the language, learn good practices.
the API sketch includes methods with boolean parameters - that hardly inspires confidence (see Clean Code for a discussion on why).
I found this one very useful. Threres little to no actual code, but talk programming principles on how to write good code.
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Clean Code
by Robert C. Martin
Download LInk: http://vitoex.googlecode.com/.../
Amazon LInk: http://www.amazon.com/.../
Summary: (From Amazon.com)
>Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way.
>Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship . Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.
>What kind of work will you be doing? You’ll be reading code—lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft.
>Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code.
>This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.
That article felt all over the place really.
The best material I have read on the subject of code 'cleanness', are Clean Code and Code Complete.
The method I follow is variable intent, not type or anything. So I don't ever follow hungarian however I have used variables with names like rowVisible that might hold any rows that are visible.
do not feel bad, existing code bases in dynamic languages in general are harder to debug than static languages (even though they seem to be easier), ask anyone who's switched from compiled languages like c# and java into php or javascript.
mix in some inconsistent style, unclear variable and function names, no comments, or your walking into a proverbial cluster fuck.
the pain is real, i have seen this type of shit myself first hand - learn how to refactor and test, test, test. Pester should be your best friend. and to the guy that wrote that code, fuck that guy.
start with these two books: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/ref=pd_sim_14_1?ie=UTF8&refRID=1XJRKZHM57S81A1ABGM7
Very good book in this topic
I am working in a team with about 10 other developers, all of them working on the same code base. These are the things that are helping us:
- We all use the same code style template for the IDE, so an auto format of the code won't change how the code looks on difference PCs.
- We have SonarQube running on a server and we configured it together. The rules there count for everyone.
- We're all trying to follow the rules of Clean Code. Clean Code: A Handbook of Agile Software Craftsmanship is a mandatory reading for my department.
- We have weekly architecture meetings where we will discuss new classes or more difficult solutions.
- We have a weekly upskilling meeting where anonymous questions will be answered.
In general I would say: Use as much technical helpers as possible to force an equal looking code base. I once worked for a company where they tried to force an equal code style by handing out a 50 page manual on code style. That just doesn't work if there is no technical helper to check that style. Better try and take a default code style for the given language with a helper to check it (CheckStyle, StyleCop, ReSharper...).
There is an amazing (and very opinionated) book called "Clean Code: A Handbook of Agile Software Craftsmanship". It explores so many hard core concepts and ideas in a reasonably entertaining way. You will disagree with parts, you will agree with parts and parts will completely confuse you - but I had so many aha moments reading it. http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
I think the guy that wrote it does this weird and wacky video series at http://cleancoders.com - definitely worth watching some of the free previews, if for nothing else then the hilarity!
Yep honestly I think this article was terribly done. I highly recommend this book for writing clean code.
Project Management has very little (read: nothing) to do with class structure.
When you say class structure I read clean code: http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
When you say project management I read Agile: http://www.amazon.com/Succeeding-Agile-Software-Development-Using/dp/0321579364
Both of those books are very good, and I would recommend them both if you haven't read them. Traditional project management is also a skill to learn, but I would recommend learning about Agile first. The use cases are different, but most often in software development, agile processes are preferred to traditional project management.
Clean code sounds really interesting! http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
You should definitely keep this as a reference in the early days: http://www.oracle.com/technetwork/java/codeconventions-150003.pdf
And pretty much the basics have been covered here. Another rule (and everyone at my company has) is that each class should have one purpose.
For instance we have classes which consist entirely of building a screen with Swing components, including assigning them constraints and then we have a class which is suffixed *Logic and instantiates UI class but contains only what the screen does, not how it looks.
This book helped me a lot in my earliest days: http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&qid=1431153823&sr=8-1&keywords=clean+code
I see there are two clean code books.
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
http://www.amazon.com/The-Clean-Coder-Professional-Programmers/dp/0137081073
Both by the same author. Are both recommended?
It's a big subject, from how to format your code over error handling to test driven development.
Personally I liked this book:
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/
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
> 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:
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:
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 (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 not...how 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:
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:
and..well..here.
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
Enjoy.
Uppercase Keywords Terminate with Semi-colons Commas go AFTER the selected Column Align the end of select, from, joins, and, etc (This is flexable across the dev's) Join columns all on one row (we have large monitors) Variables are camel-case with small first letter Constants (declared and set once at top) are UPPERCASE_AND_SPACES_UNDERSCORE
Image: http://imgur.com/kzDBsXY
We take tips from: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Then you write crappy code. Code should aim to be self-documenting, to read like a story.
Read this, be better, you're welcome http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
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...
They're not really that subjective. It's quite clear what a difference these changes make.
There's plenty of great advice in this book: http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Clean Code - A Handbook of Agile Software Craftsmanship (Robert C. Martin)
Java The Good Parts (O'Reilly)
Both books are great, with good examples.
Yeah, firstly, what the other guy said - you actually HAVE created yet another template engine/syntax, and what's more it's a pretty useless one. As he said, you're missing: "conditions, loops, filters, escaping, including other templates, inheriting other templates, and so on."
So that's a start. Also, you commented that this ensures: >your templates are HTML valid, much cleaner and shorter.
But it actually does nothing to ensure your HTML is valid at all! The HTML is only valid if the HTML is valid. Has nothing to do with this templating engine, nor should it have anything to do with ANY templating engine (if a template engine took in valid HTML and spat out invalid HTML, it wouldn't be worth using and would clearly be broken anyway).
It's not cleaner. It's less clean. This is messy and complicated - it'd be really hard to keep track of your views this way. You'd have mess all over the place - instead of going into a nice clean HTML view with very little logic and just a few variables spat onto a page with perhaps a loop or two on there just to run through recordsets, you've now got to go hunting around trying to figure out what's going on.
It'd definitely not cleaner. It's unclean code - it's also adding complication for literally no benefit at all - infact it works against you because it can't handle the stuff the other guy mentioned above.
I had a look at some of your older comments and noticed one where you boasted about your HTML widget generator class - you were boasting about how you'd written one massive class that has methods that directly spit out HTML, and you even argued that this is somehow better design than having (paraphrasing) "loads of classes with just a couple of methods on them in your system"
The fact that you'd make this argument reveals that you don't actually know OOP, or at least, you didn't when you wrote that comment. Having one massive class that tries to do everything is simply not Object Oriented code. You are (or were then at least) writing procedural code that happens to be wrapped in an object - that's not object oriented code. In the example here, having many small classes with only a couple of methods on them is easily a superior design.
Anyway, rant over.
Edit: re-opening rant for a moment:
Your moan about frameworks speaks volumes too. It's really only in the PHP world that people argue against frameworks as if they're a bad thing. Probably no coincidence that virtually every PHP dev I've ever met who told me they were anti-framework also happened to write really awful code that was virtually impossible to maintain. Perhaps you should try using a few frameworks? You would learn a lot from them.
Edit 2:
This comment: http://www.reddit.com/r/PHP/comments/1a9003/good_guidance_for_shifting_to_oo_from_procedural/c8w0br4?context=3
>The alternative is dozens of classes (and files) scattered all over your project Aside from that there's nothing wrong with that..
>It's wasteful and shows poor craftsmanship. It introduces lots of places where things could go wrong, requires more effort to babysit and it's an obvious rookie mistake :-/ on another /r/php thread someone pointed to this great video Stop Writing Classes
Oh god.
>It's wasteful and shows poor craftsmanship.
Oh god. That's so bad. You're saying the exact opposite of what is true. What YOU did, with the one massive class that does far too much stuff is wasteful and shows poor craftsmanship. Separating the code into smaller, more manageable, more testable classes with clear purposes and simple interfaces is actually GOOD craftsmanship and is all part of good design. The person responding to you there and then noted that you were not writing OOP:
>What you've got there is mostly just procedural code tucked into a class for organization. This is not OOP, and you will not be able to reuse code as well as if it was. For example, name is common to all form elements, yet you would have to have a name argument on every method instead of just a base class. And if you perhaps decided to add some data-xxx property to your form elements you would have to do it to every method rather than in one place.
HE was right and you were wrong.
Check out this book if you genuinely care about good design. In this book, Robert Martin actually shows you ways to FIND hidden classes in your system - to actually increase the number of classes in the name of good craftsmanship, and to help you make your system EASIER to maintain.
You are not as good as you think you are I'm afraid - if I were you I'd take a step back and take some time out to read books like this and maybe find some good online courses about the solid principles. Here's a good one, but it's not free.
Also, sorry, but I laughed out loud at your comment here: " it's an obvious rookie mistake".
Hopefully you will take my advice productively and use it to become better at your craft. It's obvious that you care, but right now your implementations are all wrong.
If you want to have a more consistent coding style, you should read these books, it was an eyeopener for me:
Clean Code: A Handbook of Agile Software Craftsmanship http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Code Complete: A Practical Handbook of Software Construction, Second Edition http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=tmm_pap_title_0
To be a better programmer in general, read these:
Patterns of Enterprise Application Architecture http://www.amazon.com/Patterns-Enterprise-Application-Architecture-Martin/dp/0321127420/ref=wl_it_dp_o_pC_nS_nC?ie=UTF8&colid=1IOKZXVZ1CIZR&coliid=I1QQ6ASO5I96RI
The Pragmatic Programmer: From Journeyman to Master http://www.amazon.com/The-Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=wl_it_dp_o_pC_nS_nC?ie=UTF8&colid=Z909XG1KHIYW&coliid=I16FOI4N0FU4JW
I find it hilarious that you have become so used to reading terrible code that you can no longer read good code.
While the example above isn't that great because the variable names are too abstract the idea is solid.
The point is that you don't need to understand the how. How you determine if foo is red is irrelevant, you just need to know that the code inside that if only happens if foo is red and bar or things also match. Thus the mental process required to understand why that if branch runs is.
- Read the variables.
In the bottom example the mental process is.
- Separate out the components that make up the if.
- Determine what each part does.
- Figure out the parentheses because the amount of info in the condition obfuscate them.
For added bonus, if you are actually debugging why foo is red then you're now dealing with a single assignment rather than parsing the if condition.
Your argument about slowing the script down isn't really valid as the time is so minuscule if you were to actually profile the code the profiler wouldn't even be able to time it. The point about consuming more memory part also isn't relevant as they second you started the PHP process you loaded 25 MB into memory. The extra few kilobytes of memory you will use due to clarifying variables is so tiny you won't notice. If you need to care this much about memory usage you shouldn't be using PHP, honestly. Write a C program that will be a million times smaller.
All these things also aren't just some stupid PHP programmers thinking their way is better. It's well documented in industry recognized books such as Clean Code and Refactoring.
Hi I think writing small projects will help only to a point. In the end your project may work but will it be readable, easily maintainable, extensible and so on (to anyone but you)....
If you are looking to improve your programming skills and not just php I highly recommend Clean Code http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882, there is another book as well called the Clean Coder which is also excellent.
Reading other peoples code is also very helpful. Check out the code base for http://laravel.com/, http://kohanaframework.org/ and https://github.com/sebastianbergmann/phpunit/, they are very high quality php code.
I can't exactly give a better alternative because on how you refactor code as it is highly variable. There are written multiple books about it^1 which span thousands of pages.
^1 Such as Clean Code and Refactoring
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 .
I see Effective Java was already mentioned. Also try clean code by Uncle Bob (Robert Martin). I am currently reading this book and it is an essential read for any professional programmer.
Also try practicing some programming Kata's which will help you understand the practices that are talked about in clean code. Start with the bowling game kata
You really should read Clean Code book and watch the the related videos :
if you put such an emphasis on commenting your code, you would benefit from reading Clean Code: https://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
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
Ok, I was just giving my opinion. If you want to be a better developer read about it: https://en.m.wikipedia.org/wiki/Test-driven_development
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: https://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 it has a whole chapter on TDD
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!
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.
Working Effectively with Legacy Code
Those are very good books, give it a try and you might thank me later.
Have a nice day to you too Inukai!
You buy a book https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 and read it. After reading it you should be able to tell what can be wrong with your code... and oh boy, there are hundreds of code smells possible (definitely TOO many to discuss in the context of a subreddit question).
But in general - to tell whether code is good or not you need other people to review it and see what's their critique on it. VERY, very rough guidelines (note - word "shit" is not used to offend anyone here, especially newbies! It does however depict state of a mind of a dev that sees any of that in code they are maintaining):
- non descriptive variable names stink. No, s is not a good name for a variable holding a user object. Neither is "list". Name things so the context is preserved and I can tell what function is doing instantly as if I were reading english. Eg. this is shit:
​
def check_list(list) list.each do |e| if e.status == 4 return true end end return false end
What does this function do? Nobody knows. It's only 8 lines of code, it's short... and it's shit. Now, imagine if you rewrote it as such:
def cheaters_in_players_list?(players_list) CHEATER_STATUS = 4 #frankly this should probably refer to Player::statuses[:CHEATER_STATUS] players_list.each do |player| return true if player.status == CHEATER_STATUS end return false end
This code does exactly same thing. It changes nothing in the underlying logic... except now you can look at this function and comprehend what it does without looking at other elements inside system. Furthermore, if this was called elsewhere in code, it would be:
players = get_players_list() do_something if cheaters_in_players_list(players)
- too many nested levels - if you need a 4+ levels for/while loop, it's likely your code is wrong. Refactor it, put branches into separate functions.
- good functions are short functions. How short? Well, getting average to below 20 lines is a good start (note - sometimes of course you have to make longer ones, these are guidelines, not rules). Oh, and make sure each individual line is not over 100-110 characters long.
- classes are nice! These too however shouldn't be too long.
- functions connected to each other should be close to each other (eg. in same file, right next to it)
- code has plenty of tests and they are all running (that's the most important thing on this whole list frankly). You don't have tests? Your code is shit then regardless of ANYTHING else you do to it.
- comments should explain your specific decisions and why if it's something unusual. Not how something works - this is explained in code.
- best function takes 0 arguments. Good function takes 1-2 arguments. If your function needs 3+ arguments - time for refactor, be it by placing them in a specific structure/class together or using multiple functions in the first place.
- naming is consistent. Is "fetch" the same as "get"? Is it different from "download"? Stick to same system throughout the whole project and don't introduce extra vocabulary unless it's something really different.
- If you have a function that takes a bool argument and it changes what to do based on a condition there - you most likely have two functions. So just write it as 2 functions, avoid long branches :P
- avoid side effects. Function that says "startServer" can start a server. Function "loadServerConfiguration" should NOT do such thing. Do only what function name promises to do.
And so on and on, I just scratched the surface of the problem for now (and this doesn't discuss code architecture at all).
​
Mate, you need a slap in the face with— I mean a read of: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882.
I'm on a hiring panel for a large tech company. Here are things I look for in a github account:
How many forked repos vs homegrown projects. A forked repo isn't a bad thing if you contribute to it. But a lot of people fill up their github accounts with forked repos and don't contribute.
Cadence of commits / checkins. One large git commit is a bad sign, rather I prefer to see smaller commits to a repo.
Code Quality, I look at the style of coding. Basically seeing if the candidate writes Clean Code
Unit Tests. For non-forked repos, I look to see if there are unit tests and the quality of the tests.
Build Badges . For non-forked repos, I look to see if there's a build badge and an attached CI server. Not having it isn't going to disqualify anyone, but having this set up goes a long way.
Readme files. For non-forked repo, did the candidate create a readme file? Does it describe the project, how to install it and run it. Or is it just a dump of code? Having a good readme file that talks about the project and shows how to run it is a very good thing. I will pick a random repo and try to run it from time to time. So if the steps in the readme are wrong, or out of date, that counts negatively against a candidate also.
> I want to write good clean code
There's literally a (good) book called "clean code":
https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
It shows that you haven't actually researched or read a book before.
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Try reading this one. Note the section on comments then come back to me.
I have actually. If you develop properly then you shouldn't need comments to explain your code.
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
I suggest reading this book for you to learn more.
I'm a web developer. I'm not claiming to be someone from valve who makes 100k+ a year, but I've done my research for the most part.
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
This book is pretty popular and has a section on comments being more harmful than helpful.
No. I write my code so that you understand what's going on without having to read comments.
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
I suggest reading this book and taking a note on the comments section where he explains that comments can be more harmful than helpful.
Well, Dan, since you decided to talk down to me about readable code, an area where I'm quite adept, without adding anything to the discourse but attitude, I thought, how can I respond? After all, you're out of steam, and anything I say from my experience you can just write off since you don't know me.
But then I thought, you know what, even a guy like you has probably heard of Robert C. Martin, who literally wrote the book on Clean Code. He probably has more respect in this area than anybody, and, strangely, he doesn't use braces in the way you do. What a joke! He wrote an entire book about code readability, but somehow messed up all of his opening braces, right? Right...
Would you also like to tell him that same line, "Don't worry you will understand one day."? I'd advise against it, since you'd come off as a condescending prick who doesn't know what he's talking about.
lol, no but a big fan of Uncle Bob's - hopefully more in the Android community will get to know Uncle Bob and his recommendations better - Clean Code for life bro!
I have been reading "Clean Code" by Robert C. Martin, and would recommend the following approach.
const MIN_TARGET_VALUE = 0;
/** * @param int $target * @return int */ public function setTargetValue($target) { if ($this->isGreaterThanTargetValue($target)) { $target = self::MAX_TARGET_VALUE; } elseif ($this->isLessThanTargetValue($target)) { $target = self::MIN_TARGET_VALUE; }
return $target; }
/** * @param $target * @return bool */ protected function isGreaterThanTargetValue($target) { return ($target > self::MAX_TARGET_VALUE ? true : false); }
/** * @param $target * @return bool */ protected function isLessThanTargetValue($target) { return ($target < self::MIN_TARGET_VALUE ? true : false); }
I do believe the names of the functions need to be more explicit as to what you are trying to accomplish. The code is self documenting, and I don't believe a comment is necessary.
Here it is, sir: http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 (This is for Java)
In case you are C++ dev.: http://www.amazon.com/Software-Development-Principles-Patterns-Practices/dp/0135974445
You won't be disappointed.
Codeacademy for the basics
SICP, because you'll need some formalized background for datastructures and algorithms: http://en.wikipedia.org/wiki/Structure_and_Interpretation_of_Computer_Programs
For testing, probably something like this:
http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_3?ie=UTF8&qid=1431931352&sr=8-3&keywords=unit+tests
You have a long road ahead of you, good luck.
It depends on the definition of good programming, for some it means "difficult and cool programming."
For me, as a software architect, it means clean modular code that has good separation of concerns and has a unit tests. Using these techniques I've built software for many size businesses, from small startups to large national brands. I always encourage my teams to read Clean Code
Clean Code really helped me write better code and I'd recommend it to anyone. I think you'll get the most out of it if you've already started a largish project before reading it as it will make more sense and you can immediatly start to apply the things you've learned by refactoring your own code.
Clean Code: A Handbook of Agile Software Craftsmanship Robert C. Martin http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
in reading Clean Code I remember that they advised against this approach - though I do not remember exactly why.
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.
In the classes I teach, I emphasize that working code free of any bugs can still be "bad" code. Sure, an app that is 100% meets the specification is great, but how maintainable is it? Is the code organized and architected to make it easily to extend. Does it follow best practices? like the removal of duplication and using correct abstractions. In the long run this is the measure of good code, basically most of the stuff in Uncle Bob's Clean Code book. Is the code testable? Having a suite of unit tests covering behavior is such a big deal for refactoring and just making sure stuff doesn't break.
When learning programming, people focus on syntax and getting things to work, which is great. But any time in the real world as a programmer and you realize it's easy to build something functional that you don't want to maintain. I've seen many jr devs afraid to touch a project, because one small change could bring the whole thing down. That's a sign of "bad" code, even if it fulfills the spec 100%.
A few aspects that make code code (imo):
- The DRY principle (don't repeat yourself)
- No magic strings in code (look it up)
- Not mixing presentation with application/business logic
- Good naming conventions for functions and variables (something like int x is bad).
- Not making functions or methods too long. Anything over 20 lines of code is too long and should be broken up in multiple smaller functions.
There's obviously so much more. I'd highly recommend the Clean Code book. It's a worthwhile read. I know myself and a bunch of other programmers had to learn this stuff after University while on the job and I can tell you first hand, following these principles have made me a more efficient and better developer.
I highly recommend Clean Code for programmers looking to improve the way they write their code. Beginners and experts alike will learn something useful from this book.
There's also a chapter on comments and why they should be avoided. :)
EDIT: There is also the classic book Code Complete 2. It's a bit of a longer read though.
agreed. There are instances where a well placed comment can make a huge difference. OPs code, IMO, could do without. An excellent book with a whole chapter on writing good comments
Everyone needs to read Clean Code. Not about ASP or VBScript, but will make you a way better programmer for reading it and make your code way more readable, understandable and therefor valuable to the team you work with.
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.
Why so defensive? Is it inconceivable that you might not know something about programming? Is it impossible that I might be capable of teaching you something fundamental about well-constructed code?
Your mind has thusfar been so completely closed off to the very notion that comments could be anything but helpful, but I'm telling you you've got a long way to go to reach "mind blowing" status if you still think comments are a "sanity check", even in a math-heavy environment.
I'm guessing you're still a student, and I'm guessing your teachers force you to add comments everywhere, the more the merrier, right? They're wrong, quite frankly, and you don't have to take my word for it. There are plenty of other resources for you to draw upon that will better explain how harmful comments can be to code (and those were what I found after a single minute of Googling, combined with a few books I've got with me here).
Is there a place for comments in code? Yes, but only because no one is perfect. I don't care if you think you have to be some kind of rockstar programmer who never makes a mistake, but the fact is, if you're commenting liberally, you're not a rockstar coder. Period.
And don't worry, you don't have to admit you're wrong here, all I want from you is to look into the links I've provided (specifically the Clean Code book, it's really great), and the next time you're about to slap a comment on something, I just want you to think, "can I do better?" You can, you almost always can.
Code style is very important, not just for yourself and for others. Naming a variable should require some thought and can be difficult and times. If you can't think of a good name for a variable, you might not be attacking the program in the right way.
These are two great reads on the topic, and each has dedicated sections on the art of naming variables. See if you can pick them up at your local library:
Clean Code: A Handbook of Agile Software Craftsmanship
(I prefer the first one, personally.)
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.
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.
I’d recommend to read Clean Code as a start. It java heavy but most of the concepts are applicable to dotnet. https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=nodl_
Could you elaborate on the src folder ? I have read your link but the explanation is pretty weak. Like if src folder was for Java dev only... I have never used Java and I still like what offer a src folder. Code comment is only a necessity for badly written code see this book for more
If you read this book you wouldn't need that one.
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.
Popular alternatives to Clean Code: A Handbook of A...
Code Complete: A Practical Handbook of Software Construction, Second Edition
