#CodingBestPractices #ProgrammingStandards #Python #JavaScript #CodingProblems
Hey there! It’s great to hear that you’re learning Python and JavaScript with the goal of changing your career path. It’s totally normal to question whether you’re coding correctly, especially when you’re self-taught and not receiving feedback from peers or instructors. Let’s address your concerns and explore whether there is a ‘correct’ way to code.
##What is ‘correct’ coding?
💻 Coding is a creative process, and there’s often more than one way to achieve a desired outcome. However, there are certain best practices and standards that can help ensure your code is efficient, readable, and maintainable.
###Coding standards and conventions
– Different programming languages have their own best practices and coding conventions. For example, Python has PEP 8 (Python Enhancement Proposals) which provides guidelines for writing clean and readable code.
– JavaScript also has its own set of best practices, such as using camelCase for variable names and properly structuring your code.
###Code efficiency and optimization
– ‘Correct’ coding also involves writing code that is efficient and optimized for performance. This includes minimizing redundant code, optimizing algorithms, and managing memory usage.
###Maintainability and scalability
– Writing ‘correct’ code also means considering the long-term maintainability and scalability of your code. This involves using clear and descriptive variable names, organizing your code into modular components, and following design patterns.
##Am I overthinking?
🤔 It’s understandable to feel like you may be overthinking the concept of ‘correct’ coding. However, it’s important to acknowledge the value of adhering to coding best practices. By doing so, you’ll set yourself up for success as a programmer and contribute to the overall quality of the code you produce.
###Seeking feedback and learning from others
– While self-learning is commendable, it’s essential to seek feedback and learn from experienced programmers. Consider joining coding communities, participating in code review sessions, and contributing to open source projects as you mentioned. These experiences can provide valuable insights into different coding styles and standards.
###Utilizing resources for self-improvement
– There are numerous resources available for learning about coding best practices and standards. Online tutorials, coding forums, and books on programming are great ways to expand your knowledge and gain a deeper understanding of ‘correct’ coding.
##The importance of ‘correct’ coding
🚀 Embracing coding best practices and standards can benefit you in several ways as you continue your programming journey.
###Career advancement
– Employers value programmers who adhere to coding standards and demonstrate a strong understanding of best practices. By honing your skills in ‘correct’ coding, you’ll enhance your marketability in the tech industry.
###Collaboration and teamwork
– When you eventually transition into working within a team or contributing to open source projects, having a solid foundation in coding standards will make collaboration smoother and more productive.
###Code quality and longevity
– Writing ‘correct’ code contributes to the overall quality and longevity of software applications. Clean, well-structured code is easier to maintain, update, and debug, benefitting both you and your end users.
##Conclusion
In conclusion, while there may not be a singular ‘correct’ way to code, embracing coding best practices and standards is essential for your growth as a programmer. You’re not alone in questioning whether you’re coding properly, and seeking feedback and learning from others can provide valuable insights. Remember to utilize resources for self-improvement and recognize the importance of ‘correct’ coding for your career advancement and the quality of your code.
Remember, coding is a journey of continuous learning and improvement, and your commitment to embracing ‘correct’ coding practices will undoubtedly elevate your programming skills. Keep coding and exploring, and don’t hesitate to reach out for guidance along the way.
Good luck, and happy coding! 🌟
TIA
There’s certainly better and worse code. But there are often multiple good ways to approach a problem, and which one you pick is a matter of your taste, experience, and priorities.
If you’re a beginner: your code likely sucks. That’s okay. Over time, as you build more complex projects, and as you work on established complex projects (open source is a great idea), you’ll improve.
There are also books on design patterns and clean code. You might try reading them.
There isn’t one objective correct way to code but there are two critical elements that make your code better or worse. There are best practices, which can be found online, as well as reasoning. These are naming conventions, code structure, modularity, commenting, readability etc.
The other is computational efficiency. Solving a problem with as few instructions as possible.
There are other elements to practice but these are big ones.
priorities matter, not the actual structure of code.
* does it do the thing it needs to do
* can i show it’s doing the thing it needs to do
* can other people see that it’s doing the thing
* can other people see how it’s doing the thing
* is it doing the thing with good enough efficiency
* is it going to scale the thing enough
* is it doing the thing fast enough
* how can the environment (including config/parameters) break the thing it’s doing
* when the thing goes wrong, can i diagnose how it went wrong at runtime
* when the thing goes wrong, does it fail in a safe and appropriate way
* when the thing goes wrong, can the user see this and react meaningfully to it
* can i modify the thing it’s doing in the future in the obvious ways that i can predict with a few minutes thought
* can i reuse this thing if necessary
I highly recommend looking up articles/videos on good programming practices. Videos especially are good for casual learning while relaxing.
You might not remember all of it, but it should definitely steer you towards the right track and help you a ton when you’re feeling like this. Good luck!
There isn’t one correct way. There’s different trade offs you can make, and your can certainly write code that technically works but a lot of people would still call bad (for example, misleading variable names).
But it really depends on the context. A lot of the time performance is far less important than maintainability, for example.
I wouldn’t worry about coding it the right way atm.
Make sure you’re mixing “learning coding” with “learning CS.”
no. all code is garbage. dont get hang up on that.
also, most code on FANG level companies is re-written every 4 years, due to tech advances, and people medium time staying on each job is 2 to 4 years max.. dont quote me on that btw, source: i heard it somewhere.
You will likely have imposter syndrome about this for a long time. I’ve been coding for over 20 years and I’m still learning new things.
That being said, there are several aspects that make up “correct” code
1. **Computational Efficiency** – This is the matter of finding the right algorithm and right structure to store your data. What does “right” mean? It depends. Maybe you want to optimize the amount of memory, or perhaps you want it to run as fast as possible. Or maybe you want to write as few lines of code as you need to. You learn these things and more by studying *computer science*. Most jobs don’t require an intimate understanding of algorithms and data structures, but if you work in high performance or resource constrained applications, or work at scale (i.e. Amazon, Facebook, etc.), then a strong understand of computer science fundamentals is absolutely essential.
2. **Architecture** – Once you start building larger and larger programs, you will quickly find it gets more difficult to organize, modify and maintain your code. The way you structure and organize your code is called *architecture*. This is also an entire field of study. It helps dictate how to organize your code, how to define abstractions, how the different pieces of code talk to each other, etc.
3. **Testing** – Correctness also means getting the output that you expect under all scenarios. The best way to ensure this is writing tests. Tests come in all types and flavors: functional tests, smoke tests, end-to-end tests, unit tests. The easiest to start off with is unit tests, which are used to verify that a small unit of code (e.g. a function) does what it should. Testing is something developers typically pick up later on, since you need to understand how to write and reason with code fairly well. It also ties heavily into architecture, since writing “testable” code is a whole subject in itself.
There’s probably a few more areas of “correctness” but these are the big ones. That being said, don’t worry too much about this at this stage. At the end of the day, most code in the wild is crap. No one is going to peer inside your program and make fun of you for using an array when you should have used a dictionary. All that matters is the program does what it should (most of the time).
There’s no correct way, but there are common solutions to common problems – they are called [design patterns](https://www.wikiwand.com/en/Software_design_pattern). They are universal to a large extent and can be applied to any language.
There are also coding standards that are widely adopted. These standards can be enforced by so-called linters. In the JS world, it’s the [ESLint](https://eslint.org/) tool that is used to enforce these standards.
[The Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript) is a popular one. One of the reasons I personally like it is that there’s reasoning behind each rule, so instead of blindly following the guide, you can learn why a certain rule is enforced. There are more style guides, of course, [Standard JS](https://standardjs.com/) is also a popular one.
Usually professional code strikes a balance between efficiency and maintainability. Highly lean, efficient code is usually a pain in the ass to maintain and really maintainable code can be fairly bloated. There often is a way to get 90% of the way there on both.
However, the right way is by and large making sure you’re following a coding and formatting standard. These may change depending on the company you’re at, but if everyone is formatting their code the same way it’s much easier to work on as a team.
I’d definitely keep doing what you’re doing. A lot of classes have you design a base program. Teach new things. Then have you continue to build on/refine what you’ve already done. The first step is where you are, and it sounds like you’re doing great! Keep up the good work.
The best code is conversational. If someone else can come along, read through your code, and know what it’s intending to do without having to fire up a debug session (and anything esoteric is well-commented), then you wrote good code.
Yes, there is a correct way. But no one has figured it out yet, so until then we’re stuck with the current clusterfuck.
That’s the talent…. figure out how to build an application with all the incorrect ways 😀
It depends on what you mean by “way”…
1. Is there a correct STYLE to program?
A. No, but there are definitely wrong styles. Pick one, and consistently use it.
2. Is there a correct LANGUAGE to program in?
A. It depends on the task. Some tasks have many languages for the job, some only one, and some none are a good fit for. Though for every task there are bad languages to choose – you wouldn’t program a website using x86 assembly.
3. Is there a correct ALGORITHM AND DATA STRUCTURE to use for a specific problem?
A. Definitely yes! Algorithms are king.
4. Is there a correct BUILD PROCESS to use?
A. Not really, but you’re not doing yourself any favours making this harder than necessary.
no. There is only effective, and ineffective, given a variety of goals.
When something is effective in many ways at once, and also in a small size, it is generally called “elegant”
When something is effective in one way, but ineffective in many other ways, it is called “dirty” or “messy”.
When something is done in a traditional way it is “up to standard”
When something works, but is not traditional in many other ways, it is usually called “hacky”.
When something is both elegant, and hacky, developers get out medieval arms and begin a battle to the death.
but, is it *pythonic*?
Depends what your goals are. If you want to get a prototype together asap,then go full monkey. Once you have proved your concept, It would need to be rewritten from scratch. This also can work if you want to look good in the short term and then move on quickly ( leaving a mess behind you).
There is one correct way to code. The code needs to run. Compile, start, not kp or die right away, and hopefully do helpful things.
Everything else is degrees of making your life (and others) better. Do that. But don’t obsess. The most valuable feedback on how to make things easier you only get when you look at your own bad code, or other’s bad code (unfortunately). Or if you’re lucky, good code, and learning from it.
And really, it’s that way because while there is only one correct way, making it better is evolutionary.
Yes youre doing it wrong. Im doing it wrong, most people are doing it wrong (to some degree).
Theres simpler ways to write code, less resource intensive, faster, or just arguably better practice. Theres always improvements that can be made and proper planning can help prevent some issues.
I think its good to go for best practices and ask people to check over your code and offer advice. Either way you’ll always be improving and learning better ways to do things.
Yeah. Cleanly, properly formatted, and commented.
You’ll be amazed at how much easier it is to follow when you forget what the hell you were doing!!!
I had teachers that were ball busters for things like ‘magic numbers. ‘ — hard coding numbers into things like for loops instead of us.ing a variable name so that it makes sense….there are whole books on the subject…
A value returned is a value checked. Syntax without design is nothing. Even the simplest script of only one line must be maintained. Neatness counts and consistent style is critical.
Yes, does the code do what you want it to do. It’s correct
Not really. This isn’t a math problem that has similar derivations to the end. But, there is better code and worse code, and some of that comes down to your preference based on things you’ve read.
If you search for “well written open source code”, I’m sure you’ll find some links to the code. You may not understand what it does, but pay attention more to its structure.
For me, I think about the following
* Picking good variables names (not x, y, z). It can be quite hard to think of good names. It should be descriptive and accurate. Some people name variables badly and what it looks like it’s about is not what the variable does.
* Similarly, picking good function names. If you do OO stuff, then picking good method names (which are basically functions) and class names.
* If you’re into OO, don’t make a class do everything. Break it up so the class is simpler.
* I like using functions a lot, even one-time functions. If I give it a good name, then it helps out. For example, if you have something like `if (code == 1 || code == 7 || code == 10)` that if statement is hard to understand. If instead you write, `if (eligibleForDiscount(code))`, and that function does what the condition does, it’s clearer what’s going on. It’s a form of commenting in code.
* Personally, although many disagree, I think writing comments can help especially if what’s going is complex. Many programmers just don’t like to write comments, mostly out of laziness, but they often justify by saying comments go out of date because programmers don’t update the comments. I think that’s a form of laziness. It’s like writing documentation. Many programmers hate doing (in a Wiki, for example).
* Keep functions fairly short if you can. Beginning programmers often write huge sprawling code in one function because they don’t know how to refactor. Since I use Java, most IDEs are pretty friendly to refactoring (Extract Method). I often start with function calls as if it’s pseudocode, then I think about what the functions should do. By short, I mean, 50-100 lines. The longer it is, the harder it is to read. If you have to scroll though page after page in a function, that’s a pain.
* As others have pointed out, programs are also social in nature. You may leave your job and someone will have to read your code. Sometimes being too clever makes the code hard to read, so sometimes I think of dumbing it down and not being so fancy. It took me a while to realize other people (including you) may have to read the code. Many programmers when looking at old code think “what was I thinking?”.
There are things I don’t do but OO folks who are serious do. Things related to the SOLID principle, stuff about class cohesion.
* Indentation. Beginners often don’t care about it, but it helps people understand what the code does. It really makes the code hard to read. Know how to indent (you can use the IDE to indent for you, but I think knowing how to do it is important).
* Try to avoid lengthy lines of code. I think about 80 characters wide, maybe I’ll go higher, but if it goes longer, I’ll split say, a function call, into several lines. It’s a pain to scroll really far to the right to see what’s going on.
* DRY (don’t repeat yourself). If you’re copying and pasting code in several locations, you may run into the issue of having buggy code in many locations and you would have to fix them all and be sure you caught it everywhere. Make a function and have that code in one place, and call that function instead of copying and pasting.
There was a book in the 1990s called Code Smells that explained when code “smells” like it’s not well written. I don’t know if it still exists, but the 90s produced a lot of interesting books. Design Patterns (yes, a programming book) got huge, but then some programmers took it too far, and arguably, some claimed Design Patterns was about dealing with inadequacies in a language.
Basically, you read about good programming, good style, and just try to take in all the advice you’re getting and you form your own ideas of what’s good and what’s not. At a company, you ought to do code reviews, but it just depends on who is reviewing your code if they have anything meaningful to say.
Hope that helps.
Yes, but it’s a secret only the rubber ducks know. We will get there some day.
I like to solve a problem in increments.
Break down the black Jack game for instance.
1. Needs a player object
2. Needs a deck , list/array of numbers or card objects with face value and type
3. Need the basic mechanics, such as a player can enter options somewhere. So something like a GUI button set or terminal prompt that listens and accepts predefined options… Maybe enums or final array/collection of acceptable strings the user can use such as HIT or DOUBLE DOWN or STAND etc…
4. After the game mechanics work I would work backwards and create a “game” object to contain an object oriented implementation of step 3 above.
5. Need something inside the game object for checking game status, i.e what options should be available to the user and if someone has BUSTED or won in that iteration.
6. Go back over everything and try to simplify large logic sections into valid patterns if I can visualize a better option.
This is my general, ADHD, approach to software development of new features/stories. There usually is more that goes into this as you tend to develop a better understanding of the codebase you are working in over time.
Much has already been said here, and most of it good. So I’ll just add this:
while there are better and worse ways of doing things, there are also definitely wrong ways of doing things.
However, more important (at least early in learning, when stakes are low) than doing the wrong thing is realizing “perfection is the opposite of complete”.
Huge successes and amazing works have built on mountains of wrongly coded, best practice defying, down right god awful ugly unintuitive code. Focus on being able to do “the thing” over whether a fellow dev will give you a gold star or troll you.
Disclaimer: statutes of limitations apply here. If you build a pace maker or flight control module w this methodology, you suck 😜😅
My way is the best and the only correct way to code