-3

I know there are many books on writing clean, modular, readable and whatever else you can say but frankly speaking I find it very hard to remember every advice given on those books. Frankly speaking either you know things or you know nothing at all and find it very difficult to relate to your daily job I think it's so because it speaks the mind of the author and what experience he has not your. Also I am not a very gifted person who can stuff a lot in memory.

Coming to the point in my experience every code tells a story or a pattern and we have to just seek that pattern and try to reduce the repetitive part as hard as possible. Is it a good rule of thumb to apply in any programming language?

Edit:

After some comments and answer I would like to clarify to future readers that in no way I am abusing any book or author or neglecting the usage of any book completely.

closed as unclear what you're asking by Philip Kendall, Greg Burghardt, Eric King, amon, Basile Starynkevitch Jul 19 '17 at 15:38

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    This question seems to boil down to: Is “look for the pattern and reduce repetition” the golden rule of clean code? I've voted to close, since this question is primarily opinion-based: I personally think this rule misses the point because I value other things, others might think it is perfect because it helps them. Additionally, this question talks about learning strategies. You note that you don't learn well with books. Help with that is generally considered off-topic as well, and everyone has to find their own way that suits them well. – amon Jul 19 '17 at 15:39
  • Unfortunately the way the question is phrased, the answers will be opinion based. The main strategy for newer developers should be to stick to rational, logical development techniques. Avoid cargo cult design techniques, specifically those that insist that good design is the result of a process requiring no thinking -- good design always requires thinking, and cannot be created by following simplistic "principles". – Frank Hileman Jul 19 '17 at 15:50
  • 1
    If you're looking for one programming principle to rule them all we haven't found it yet. If finding a way to apply what you've learned my advice is this: book club! Don't be the guy in the meeting that insists we use dependency injection because of the latest book you read. Programming books are an expression of shop culture. So read books with your team, not at your team. Decide together if it's ideas should be your ideas. Nothing is harder to understand then a code base created by people with competing philosophies. – candied_orange Jul 19 '17 at 15:54
  • I suspect there is an clear on topic question hiding in here but since you've already accumulated answers editing is not likely to help at this point. Think about how to ask what you want to know some more and come back to us. – candied_orange Jul 19 '17 at 15:57
  • 1
    This is a discussion better suited for Software Engineering Chat, I think. – enderland Jul 19 '17 at 17:28
6

Software patterns are mostly about vocabulary. They give software developers a language by which they can communicate high-level design concepts.

But patterns are not a design methodology; if you're trying to write software by stitching together well-known software patterns, you're probably doing it wrong. What you really need is an effective architecture.

Here's a better rule of thumb:

Strive to write your programs as a series of small functions that each do one specific thing and do it well. Have them accept parameters, return a result, and create as few side effects as possible.

You can do this in any programming language. If you follow this precept and nothing else, your programs will be better than 95 percent of those programs written by new college graduates.

Don't read books to follow new rules. Read books to expose yourself to new ideas. Incorporate those ideas that make your software better and make you a better software developer.

  • 1
    Comment your downvotes, please. – Robert Harvey Jul 19 '17 at 15:47
  • I never said that there has to be same pattern what I am saying is that every program has some pattern and there should be an effort to identify those patterns. – CodeYogi Jul 19 '17 at 15:53
  • I guess it depends on what you mean by patterns. A for loop is a pattern. Simply identifying patterns in your code is a useless exercise unless it is in pursuit of some specific objective. When I hear the word "patterns" bantered about on this site, I think of the GoF book. – Robert Harvey Jul 19 '17 at 16:16
  • then in that case you are mistaken. I am assuming pattern as some high level concept eg writing similar code to save some object to some persistence layer. – CodeYogi Jul 19 '17 at 16:21
  • This may be off topic but which you would recommend except code complete? – CodeYogi Jul 19 '17 at 17:10
3

Each discipline, would it be accounting, archeology or brain surgery, has numerous books and numerous things to remember. Yes, you have to read a lot of books in order to acquire the minimum knowledge needed, and no, you won't be able to remember everything which is written in those books.

Reducing all the principles related to clean code to one paragraph and claiming that you don't need to read any book any longer won't help you. It just doesn't work that way, and it won't help you become a professional developer.

we have to just seek that pattern and try to reduce the repetitive part as hard as possible

There are parts of code which have no specific patterns.

There are cases where code duplication makes sense, because the fact that the code looks identical is just incidental.

There are plenty of cases where the difference between clean code and unclean one would result from something which has nothing to do with patterns and code duplication. One example is clear, self-documenting variable names.

  • I fear that you are going completely off track. I never told reading books are bad it's just it doesn't fit in my framework. – CodeYogi Jul 19 '17 at 15:47
3

Hopefully learning is an iterative process. There are things that are not useful at the moment, but you'll remember some. Problems come up that you'll research. You will misapply them, but that's part of the learning. As you do things, you'll remember more. I've probably forgotten a lot of particulars of many languages than I may even know about the current languages I use. Certainly, I've lost fluency.

There is no reason to think you need to learn everything in a programming manual like you're studying for a final exam. They're meant to be opened many times. Eventually, you won't have to keep looking up the same thing over and over if you're using it enough.

Refactor what you currently know is not the best way to do the job. Maybe you learned something new. The problems in your code can lead you to new solutions just like a good mentor or some pod cast you listened to.

Having an encyclopedia of programming knowledge comes from years of experience if you've been doing real programming. Sure it helps, but it is not the end all of being a developer.

Just keep coding, recognize what doesn't work, and be open to new solutions. You don't have to know everything right away.

  • I am saying same that if I am not able to memorize thing then also I should be able to atleast write good code. – CodeYogi Jul 19 '17 at 15:49
  • @CodeYogi - There's more to being a professional programmer than just writing code. You have to develop some fluency or you won't be productive. Things used repeatedly need to be memorized or at least have a cheat sheet. I doubt you need to memorize the complete syntax of a database connection string. – JeffO Jul 26 '17 at 13:12

Not the answer you're looking for? Browse other questions tagged or ask your own question.