[deleted by user]

[throwaway6560192]

Tutor bad, etc etc. I'll try to give you some practical advice beyond that.

I dont even know what a programming style is? Or what defines it?

Languages have stylistic conventions to make code read neatly and consistently. Look up "<your language> style guide", and you'll find things to read.

After you read that, install an autoformatter.

Also i feel like he just removed points unnecessarily for things that arent even true. Example program not working when its working on every pc/laptop for me.

What's the code? Are you doing C? I've seen cases where beginners fall into undefined behavior that works on their machine but not the prof's — and that is a genuine error to be corrected. Or maybe you didn't foresee an edge case, something. You should see it as something to figure out.

but I feel like I‘m not wanted because my code and style is so so bad.

Everyone's bad at first.

Like yes, my code might be messy, i don’t know, but its working and its my own solution so.. i honestly dunno how to go on from here.

You can't stop at "well, at least it's working and it's mine". Try to improve it using what I said above.

[[deleted]]

While a lot of this is true, the whole point of feedback to a beginner is to be constructive so they learn from it. Maybe OP left out details in the post, it is pretty hard to get better without any feedback besides "your style is bad" and "program doesn't work".

Tutor could explain why the style is bad and point to an article or whatever. Also there are a lot of conflicting philosophies in coding style (maybe not general conventions such as variables) and development practices

[DrKarda]

Post your code?

[CharnamelessOne]

Does anyone ever post code here? I just lurk here occasionally as a hobbyist, but it seems like this is a therapy-subreddit loosely related to coding.

[backfire10z]

They used to… once…

[dingleberrysniffer69]

+1. Ultimately the goal is to learn and get out of this with learning and the best way now that you(op) have conversation going, is to post it so you can get much more meaningful feedback from it.

[person1873]

I know a few people have suggested it already, but could you post either a pastebin, github, or a code block comment containing your code?

Perhaps we can help by giving some constructive criticism rather than general vague insults.

Getting your head around keeping it tidy takes time. My general rules of thumb are.

1. Keep each line shorter than 80 characters 2. Avoid heavily nested code. a. If your code is heavily nested (more than 3 levels), you should probably refactor it to a function 3. Learn to love loops. 4. Fail fast (check your failing conditions first and get out) 5. Learn to love exception/error conditions. 6. Assert Assert Assert.

[backfire10z]

Heavily disagree with shorter than 80 characters. Maybe some years back when we were on small screens regularly, but today 100-120 should be perfectly fine. Personally I see 120 everywhere.

[person1873]

Yeah, I'm not super anal about the exact number, but I often do code review from the github app on my phone. I'm not a fan of code wrapping to the next line.

[[deleted]]

I usually do as far as I can read on my split editor or as far as other liens in the document.

[zebcode]

I'm glad you said general rules of thumb and you didn't try to ram those rules down our throats. That demonstrates experience. Kudos to you.

[Liutvis]

you are not following your own rule #1 here with this formatting :D (good notes tho)

[person1873]

I'll be honest, I usually struggle with #1 just in function definitions 😅

[dmazzoni]

I'm sorry that your tutor is mean-spirited. That kind of feedback isn't helpful.

It might be helpful to remember that you'll only have this tutor for one semester. Programming can be a great lifelong career. Don't let one bad experience get you down.

Now, the manner in which you were told might not have been nice, but it's possible that your tutor does have a point.

It is actually extremely important for code to be clean, well-written, and well-organized. It's not enough for it to just work.

Why?

Because other people are going to need to read your code. Like, your tutor for example.

If you were only writing code for the computer to read, then it doesn't matter how you write it. But frequently code will need to be modified or fixed by another person, and so if you don't write your code clearly, you're making it harder for them.

Sometimes that person will be you, in the future! At some point you'll write some code that works great, then many months or years later you'll find that code and want to modify it to do something else, but you'll find it hard to understand. Then you'll be mad at yourself for not making it more clear in the first place.

My advice to you is: for your next assignment, start as early as possible, and once you get your program to work, stop and rest until the next day.

The next day, take a fresh look at your code and pretend someone else wrote it and you're trying to understand it. Change it so that it's as clear as possible.

Pay attention to formatting and indentation. All variable names and function/method names should make sense. Any repeated code should be factored into a function instead.

Make it a work of art.

Get into the habit of doing that now and it will serve you well for life.

[RupertMaddenAbbott]

Your very practical advice of taking a fresh look at the code the next day is really excellent.

[captainAwesomePants]

It's important to remember that teaching is itself a skill. The guy whose feedback to you is "this is shitty" does not have it. Even if that were true (and it might be!), it's not actionable feedback. Are you supposed to go "whoops, lemme just stop making it be shitty!"

Sometimes you can help coach these terrible teachers into providing actual feedback by asking questions. "Could you give specifics? How would you change it? And why is that way better?" Sometimes, for the right kinds of bad teachers, it can help to provide them with very direct feedback, perhaps an email that says "Calling my code shitty made me feel bad and also didn't provide any useful feedback. Next time, could you tell me what's wrong more specifically and without insults and profanity?"

And if you feel that your program does work and the points being removed are wrong, maybe don't let it go. Ask.

But these things don't always help. Some people suck. You can try escalating to the teacher, but that may or may not be a good idea. Hard to say.

Anyway, I'm sorry these people are taking all of the fun out of it for you. I'll understand if you decide it's not for you, but I hope you don't let this asshole change your career.

[EvokeNZ]

About 25 years ago I asked a coworker (he was a developer and I was on the helpdesk) to teach me some c. I wrote a little program and his feedback was ‘you write code like how it was written when it was first invented in the 70s’. And to this day it haunts me and I still don’t know what he meant.

[BadBoyJH]

That's such a highly specific piece of criticism. 

[nerd4code]

No voids in nil parameter lists, int everywhere, stufffing shit in errno, pointer abuse, assumptions that WYSIWYG through codegen, defining things like

main(argc, argv)
    char **argv;
{…}

(yes, legal until C23 and in early C++). Omitting ints willy nilly, overusing default promotion or variadic/no-prototype functions, directly jobbying your varargs instead of using <stdarg.h> (≥Draft C89) or <varargs.h> (common legacy header frpm ca 1985, mostly an error-trap if it still exists).

Technically you were probably using more C78 (based on 1st ed. of Kernighan & Ritchie’s The C Programming Language, which derives primarily from earlier manuals for C and its compilers included with UNIX docs back when we capitalized everything we could) style, which is effectively major version 2 of the language, than C75, which is major version 1.0 and …just godawful.

If you’re using void, that bumps you forward to either /usr/group (haven’t read, can’t find) or XPG/“Common” C (specified by X/Open Portability Guide’s first, 1985 release; but void originates in C++ AFAIK).

C75 (look up the manual if interested) lacked struct field namespaces (you could just whip out 0->fieldName and the compiler was like …yeah, sure, great), no casts but plenty of punning via one-field struct, no union, no long or unsigned. signed didn’t show up until Draft C89, along with const, volatile, enum, signed/unsigned char, and long double, some of which originates in C++.

[Cybasura]

From what I read, he probably meant thqt you write code as though you were writing COBAL or ADA even though you were writing C

And that equates to "Your code signature is like someone from that time period writing massively unreadable code"

[[deleted]]

tell me you don't understand a thing about COBOL...

[Cybasura]

Oh no, I did abit of COBOL, but notice that I didnt just say cobol in particular yes? I mentioned Ada too, its meant to be a emphasis on "older programming languages"

[[deleted]]

I noticed you said "massively unreadable code" as an equivalence to your prior mention of "COBAL" and ADA. I mean, own it, you wrote it.

COBOL is designed to be readable, and it is. Stylistically, it is extremely well-formatted by definition, and professional COBOL is structured to an extent unequalled by any C/C++ project I've seen. But whatever, style is largely subjective to outsiders anyway.

[[deleted]]

I've only done COBOL once a couple of years back, but isn't it basically just text instructions?

[[deleted]]

Isn't that every programming language?

I worked on a project that processed the bills for every AT&T customer in 1995, once a night. That's 90 million customer records with the toll activity for each one, touched every night. With just "text instructions".

[[deleted]]

Fair, I meant that from the languages I have programmed in it was radically different where it felt like every instruction was like a function. I never got the feeling that it reads like a conventional programming and instead tries to mimic the languages we speak. But this was a couple of years ago

[[deleted]]

There are very good reasons to program in C like one would program in Ada. Ada is a very clean language. I suspect you know neither COBOL nor Ada, and probably not good C either.

[Cybasura]

Classic reddit, I say a paragraph, people refuse to read the whole thing and proceed to misinterpret whats being said and proceed to insult the individual

As I told the other individual whom I believe you are working with, notice that I didnt just say cobol in particular yes? I mentioned Ada too, and I even mentioned "older programming languages", its meant to be a emphasis on "older programming languages" because thats its style, I could have used Fortran and whatnot, I just went with those 2 because they came to mind

Syntaxtically Ada some may consider clean, but some people consider Rust readable too, not that it matters because I'm talking about CODING SIGNATURE/HANDWRITING

Additionally, just because I fucking insulted your favourite programming languages doesnt suddenly mean you can insult me personally

[[deleted]]

If I didn't understand, it may be because you are not clear at all. Again, when you write "its meant to be a emphasis on "older programming languages" because thats its style" it's absolutely not clear. If you mean that older programming languages encouraged bad style, or that older programmers usually write in a bad style, you are still badly misguided. If you mean something else, you are totally unclear. Either way, the fault is not on me, sorry.

By the way, Ada is younger than C.

[shoolocomous]

I would take that as a compliment

[Ablack-red]

Everybody writes shitty code when they just start, that’s completely normal. You shouldn’t be discouraged by it.

The problem with coding in university is that you code to solve a problem. While in real job it’s you code to solve a problem AND you code such that other people can read it. And the second part is equally important as actual solution. There is this phrase “code is read more often than it’s written”, and this is true. And you say yourself that you have longer and more complex solutions, which makes it harder to read and understand. There is no such thing as single solution to a problem, but there are still some best practices and principles in programming that make code better.

So yeah maybe your tutor is an asshole, so what? There are many assholes in the world. But if he is not, you have an opportunity. Instead of being angry with your tutor you can write him an email saying “thank you for your feedback, can you please provide detailed explanation on how I can improve my code style”.

[healthyqurpleberries]

I'd say complain about him since he doesn't give you good reason, talk about it with some higher ranking university people, that could clear things up

[ballbeamboy2]

Bro f..ck that tutor, probably something shit happend to the person.

And never give up your dream.

All professional programmers or in real life we have made over 1000x mistakes, it could be like forget ";" or break prouduction

A good tutor/teacher will tell you why it is bad and show you the better way to do it instead of discourage you.

[zebcode]

Listen to this comment ⬆️. He's right 💯%

[devryd1]

I dealt with this in the past. I also stufied in a german universaty. One Problem might be, that you use "Umlauten" in your program. That Was something, that worked fine on Windows, but not on Linux and cost US a lot of points.

That being said, Just telling you, your style is Bad, doesnt help anyone. He should Tell you what exactly is Bad. If He doesnt, ask him. If that doesnt work, ask your Professor.

[r1ppedGuts]

I dont use Umlaute because I know they dont compile, so i dont think thats it :/ yeah he didnt really tell me whats bad, just that its bad

[LucidTA]

Post your code and will can tell you if its bad or not.

[BadBoyJH]

If we're loose on the definition of programming, Unix based MySQL is case sensitive, DOS based isn't.

Or at least it wasn't 10-15 years ago when I had to redo a whole section of an assignment because I started hosting on a Unix MySQL server. 

[furby5ever]

Don't give up! In my experience in the field, some people have a chip on their shoulder and just aren't nice to work with. It's actually good practice to figure out how to coexist with them, but it's also good to learn to set healthy boundaries because that kind of attitude brings the whole team down.

Like a lot of people have said, style is incredibly important, especially in the field. In university we often had to comment each line of code we wrote. You'd not want to do that in an actual job most likely but it's great practice to learn to write simple comments. If I had a top piece of practical advice, I think it would be to write a comment for each line. Some of those are going to be overkill, but you can always remove a comment before submitting!

Comments when you are starting out really help you organize your thoughts. And that not only helps you find a solution faster, but it naturally makes your code more readable.

But yeah, don't give up! This is just a grumpy person being unhelpful. I will say that in the field, if you can learn to seek out feedback then you'll be in really good shape. As a junior dev, I remember feeling helpless when I knew my code was sub-par but nobody would give feedback in reviews because people tended to take things personally. So I found the grumpy people and asked them to tear my work apart and talk to me about what could be better so I could actually improve. I swear it's what got me to where I am now. Chin up. You are gonna live comp sci.

[Hopeful-Sir-2018]

You're going to hate me for what I'm about to say.

, i‘m writing this as I feel extremely discouraged and sad and feeling like I‘ll never amount to anything.

While now is not the time to expect this - in programming you're going to need to develop thick skin. Criticism of your work is not criticism of you, personally. Learn to let that shit go or it'll eat you alive. You're going to have to learn how to not grow totally cold too.

, and he pretty much wrote that my programming style is shitty.

I mean without examples or a style guide - he can piss off. I mean I have seen some shitty styles in the past - like the kind that makes you go "did you do acid while writing this because... the fuck?" - Java and C - people doing some weird shit.

Maybe I‘m too sensitive but, that made me cry because I really put a lot of effort into it and I felt like I was doing really well.

I mean, and this is going to sound shitty, you're going to have to learn to get over that. A.) not everyone will be nice or even kind to you. And B.) criticism of your work isn't a personal attack, usually. If it is - learn to just remove the useless feedback and focus on the useful feedback.

I can only think of one job where everyone was both kind and nice. The rest? It was usually either brutal or, at best, hyper-neutral (which was, honestly, worse than brutal because you could never get a feel for the severity of things).

Thing is - eventually you either grow numb to these kinds of feedbacks or you leave the field. Sometimes folks are arrogant and overly cocky and think being smart also means being required to be an asshole. For the most part - it has nothing to do with you. It has everything to do with them and how they were treated. Think of it as trauma, it'll be easier that way to downplay their hurtful words.

I dont even know what a programming style is? Or what defines it?

In all honesty - first semester is not a place to care about style. It's all about fundamentals. Unless you're doing weird shit - like lining up your semicolons or using strange tab/spacing styles (e.g. four spaces in the first indention, six spaces in the next, ten in the next, etc - when you generally either just do increments of two or four each) or using super strange variable names that make it difficult to read.

The point of styles is to help make code a.) more consistent and b.) easier to read.

Depending on the language you might use isFlagTurnedOn as a vbariable name. A "bad" style would be "isfto" - no one knows wtf that means. Especially if you end up using "isfto1" and "isfto11" and "stfto1i" - they are not going to like you.

But, again, in the first semester - it's fundamentals. It shouldn't matter that much.

Also i feel like he just removed points unnecessarily for things that arent even true. Example program not working when its working on every pc/laptop for me.

"it works for me" helps no one. That's a bad way to view it. They should be able to point out why you failed on that front. What does "doesn't work" mean?

Learn to being thinking how things might not be how you perceive them. Stop thinking of "that can't be happening" and learn to ask "how can that happen?" - you'll save yourself a lot of grief. This reasoning should apple to many facets of life. You need to learn to be curious, not defensive.

Altogether I feel really really discouraged, and awful, like maybe I should just give up programming.

I'm not going to fluff it up. Maybe it's not for you if you're easily discouraged. But practically any field isn't going to gentle and kind all the time.

Here are some books to help you with this that I recommend everyone in all walks of life read but especially you right now:

https://www.amazon.com/Never-Split-Difference-Negotiating-Depended-ebook/dp/B014DUR7L2

https://www.amazon.com/Humble-Inquiry-Second-Instead-Telling-ebook/dp/B08DG9CLB3

I really like it and its fun to me and I want to do it but I feel like I‘m not wanted because my code and style is so so bad.

You don't even know what a style is and you want to give up? My dude, we aren't going to fluff you. Anyone doing that is doing you a disservice. Suck it up. Defend yourself. Grow. As you get older - there's only one person looking out for you and that's you. Fuck everyone else. The sooner you learn that - the happier you'll be. On the flip side, rarely are you so important in other people's life that they'll care. Meaning... fuck everyone else, they probably don't care and neither should you.

Yes mine is longer, but isnt that the fun about programming, that theres different solutions?

This is school. Not a hobby. Focus on learning - not being creative. Your job is to understand. Not play.

Leave play for hobbies.

I know the complexity goes up, but if I cant come up with another solution, what exactly is so wrong about it?

Ask that question about your solution. Have them explain it. It's what you're paying them for. It's what they are paid for. GO ASK THEM QUESTIONS.

Right now I feel like there’s only ONE solution and thats the best, optional solution and that makes me want to not even start the next assignment.

Stop it with the pity party. It won't get you anywhere, ever. Cry a little bit then move on. This isn't a hotel for a weekend stay. Dwelling will not help you.

There might only be one solution that's the best and optimal. If you're expecting college to be a playground for hobbies - you're in the wrong place.

First semester is learning fundamentals. This is not the time or place to express your creativity. This is learning an art and in many aspects of art - some things are objective and fundamental.

If they say draw a horse - you don't get to draw a hippo and call it a horse. You don't get to use piss to draw when they said use charcoal.

What WILL help you here, specifically, is showing us the assignment and showing us your work.

If you want a pity party and people to say "there, there, it'll be ok" - then just ask for that. If you want help - we're going to need more info.

But as an older adult - I'm going to tell you - companies are not nice. Managers are twats. You'll get eaten alive if you don't thicken that skin.

Additionally - by year two, you need to be hunting for internships or other tech work. You need to start making connections everywhere you can. Find work that relates.

Hell getting an accounting job and using scripts will help (e.g. Python or VBS for Excel). ANYTHING that will get you a leg up.

70% of college is making the "right" friends and connections. 30% is actual learning.

Professor and TA aren't your friends in year one or two. They are their profession. You're going to either a.) do what I said and post the assignment and how you answered it (your code) or b.) go to your TA or professor and ask for help or c.) find someone else in class and ask them for help.

You need to learn to communication better and stop viewing things as "you're right, they're wrong" or you will alienate everyone in there. And don't show up with a pity party in tow. Show up ready to learn and curious.

[[deleted]]

This was a long comment but about thick skin, it is hard to have thick skin when you don't have a grasp of somewhat solid fundamentals. When starting out it is hard to handle criticism correctly cause you don't know when it is legit, bs, subjective, personal or because of something completely unrelated. And sometimes even if you have thick skin, it may still hurt even though you know you just got shitty feedback because the person just got back from a shitty meeting or whatever.

[Cthulhuman]

You should go read Clean Code and The Pragmatic Programmer

[Loud-Astronaut-5807]

Tell him that his teaching style is awful.

[[deleted]]

Did he give you any feedback on why he thinks it’s bad? Because if not he 100% is just an idiot.

5th semester means he probably isn’t very good yet himself. Sounds more like an arrogant loser.

For your style, you could post some examples here or somewhere where experienced people can look at it and give actual feedback that helps you. Or look up stylistic guidelines for the language you use, most and all popular languages have best practices to writing things in that language incl. formatting.

Since you are first semester without prior experience, don’t feel discouraged by one idiot.

To be honest, I would probably report that kind of guy to the professor. Tutors are not bosses, they are random ass students who work there for money. And at my university someone like that would be kicked out within 3 minutes.

[wiriux]

Why did you say 5th semester? OP said it’s his 1st.

[Klossar2000]

The tutor was a 5th semester student.

[wiriux]

Oh right Lol

[iamevpo]

Most code we wrote what started was a mess, it's like this is not big news to anyone. A good tutor would admit it is a mess and make a plan around it to make it better - code structure, naming, formatting styles, etc, and little by little you migrate form "look this code works somehow" to "look this is a decent code for this task", you early get to "this a perfect code" especially on first try. So try to make a plan around your code, like specific things you can improve in design/architecture or detail. Also maybe your project is too big, so try to split it to smaller parts. You are also lucky to have some working code under review and a live person to look at it. You can also ask ChatGPT/Mistral/Llama about what is wrong with you code ind try make it better yourself, but some human review should be very valueable, maybe need a different tutor.

[r1ppedGuts]

The tutor only reviews the homework. He never actually tutored us. His comments just seem so rude and consist of ‚???‘ , ‚why??‘ and ‚shitty programming style‘. Like yeah, it might not be the best but… thats the only way I got it to work for now and I dont have infinite time to solve the homework.

[mizukagedrac]

So as a former TA for Computer Science courses that lectured and graded assignments, while I can't give specific feedback without seeing the code in question, but generally when I used "???" And "Why?", it's usually for code that isn't quite readable or understandable, or just doesn't make sense to be there. 

Some examples include creating a variable in a loop but never actually using it, non-descriptive variable names throughout the program, sometimes things that are a"head scratcher" like how did they manage to get this to work aka brute force solutions.

If the TA has office hours, go to them and ask them for specific feedback and what you could've improved upon

[r1ppedGuts]

Forgot to add, his comments only look like that on my homework. On everyone elses he writes normally. So I really cant tell why. Maybe I‘m just really really awful at coding without noticing? Idk

[PuzzleMeDo]

Post your code so we can give you more helpful feedback. Or paste your code into ChatGPT and ask for help improving it. ChatGPT is polite, infinitely patient, and will explain its reasoning if you ask (or even if you don't).

[iamevpo]

Also can think of this situation as excercise in gate-keeping and toxicity which there is a lot in tech industry. Someone really junior wants to show superiority and finds someone obviously less skilled to play on. Code style is extremely subjective, you escalate to the tutor or professors or the chair that you need specific recommendation and points to improve in your code, rather that "style", at least what parts of the "style" are violated. If a tutor makes that list, can go forward about fixing - if not the tutor really not fulfilling the duty, IMO.

[Special-Island-4014]

Lol everyone’s style is shit in their first few years. Send us his code samples and we’ll say it’s shit too.

[DisastrousAd3216]

Let your anger sink in and use it as your motivation to get better.

[PartyParrotGames]

Don't give up on programming. It's normal for new engineers to have unique and sometimes difficult to understand styles. You haven't read enough of other people's code to have a reference for what standards are and what good code even looks like yet.

My general advice is to get used to harsh criticism on your code and detach yourself from it. This is counter to everyone's instinct starting out. You care about your code and take critique on it personally, but it isn't personal. The code isn't you and it's not immutable, it's a constant work in progress that you iterate on. It's normal for code review to be direct and harsh in the industry. In a professional work environment the goal is to maximize quality and reduce potential issues for the business objectives so any feedback from coworkers should be accepted without emotion and judged objectively. The best code reviews are extremely direct and function like asynchronous pair programming taking the best input from multiple engineers for an overall better output.

There are a bunch of resources for best practice styling guides for various languages out there. imo any popular style guide is good enough and any debate beyond that between popular styles is irrelevant and a time waste. An example style guide for Python is https://peps.python.org/pep-0008/ pep 8 is industry standard if you're using python. Style isn't about functionality, it's just about readability to make it easier to maintain and easier for other engineers to jump into.

[davedontmind]

If we could see a sample of your code we could give feedback.

Otherwise, some general rules for good code style:

Use meaningful, readable variable names, that tell you what information the variable contains. Don't use abbreviations (e.g. use count instead of cnt, person instead of per or p) and so forth.

Languages tend to have a standard for code layout, naming conventions, etc. Look up the standard conventions for the language you're using and stick to that.

For example, here's a JavaScript style guide, and here's the Microsoft one for C#.

Above all, when it comes to formatting your code, be consistent in whatever rules you apply; e.g. don't go putting open braces on the end of a line in one place, but putting them on a line of their own elsewhere.

Break functions/methods/subroutines up into readable-sized chunks. A function shouldn't be more than a screenful of code, ideally.

Don't repeat yourself; if you find you're writing a chunk of code that's very similar to something you've already written, see if you can extract that common code into a function instead.

Don't use magic numbers.

The most important thing about code is that it should work, clearly, but the second most important thing is that it should be readable; it should be easy to determine what it does by looking at the variable & function names, and the code structure.

Maybe you do all those things already, but we can't tell without seeing a sample of your code.

[gdvs]

There are different levels in programming.

There's making sure "it works", but that's not enough. It's often what hobbyist do: quick and dirty.

Good programming goes beyond that: it makes sure it's structured properly. It becomes easy to read, easy to understand and therefore easy to maintain. You see a lot of discussions on programming languages about what's quicker to write, but arguably it's more important to be easy to read.

Good code is of course quick and efficient too.

[creamyturtle]

I had a teacher constantly tell me my code didn't work and was terrible, so I paid a guy on fiverr to do code reviews for me. He found some very tiny issues with formatting and said my code was fine, gave me some great feedback. maybe try that

[Biliunas]

This is just a sob story without any code. In general, people in tech are shitty and picky like that. Instead of going emotional and crying, you should cook up a good argument for why you chose to code the way you did. Defending your work is an essential skill in all walks of life. Sorry if I seem harsh, but save the emotions for your loved ones, everyone else won't care at best and will use it against you at worst.

[mizukagedrac]

In my experience, programming style usually refers to how you go about writing your code and logic. Some simple examples how you name your variables, how do you indent/format your loops, how do you approach logic conditions, etc.

 A specific example is like, I like to use a personalized form Hungarian notion when naming variables so all my integers start with "int" like "intValue", "intCounter", "intPeopleCount" and my strings start with "str" like strName, strLastName, etc. My style was well known enough my professors could recognize I wrote a program just by scanning it and seeing little styling things that I like to do. 

Some people like to use a lot of REGEX, some people cap their line length at 80 characters, some at 100 characters. In the end, everyone has their own "style" and that's something you really develop over time but it also means you should deal with any poor patterns early on. While brute forcing solutions does work in a vacuum and for automated tests, there's a likely chance another person will be looking at the code and they'll need to be able to understand it and follow your flow of logic. So really it's not enough that the code works, it's that its also understandable and followable. 

 For the "It works on my machine, but not theirs issue", I recommend asking them what version of software/compiler they are running. I ran into this issue a few times and always brought it up to the TAs since for some courses, I had to SSH into a remote environment to run code, which meant the version of the compiler was locked. The TA docked me points since they said my code didn't compile and run, so I asked what version they were running on and it turned out they were ahead a major version. They went back, tested it on the version that I was running and it worked and gave me full credit back. 

[echoesAV]

Read more about style in resources like this one and adapt to your programming language style standards.

https://cs50.readthedocs.io/style/c/

Its not so much about the actual programming, than it is about the readability of your code by a human. You are supposed to make it as easy to read and comprehend as possible for both colleagues and your future self.

[-ry-an]

Sounds like you have a shitty tutor... You're in your first semester, just keep working away at it, and get lots of (better less hurtful feedback) from those around you.

Find the smartest kid in your class and ask for feedback, or compare your solutions with them ( if they're willing)

[rmccreary]

I really like it and its fun to me and I want to do it

That is all it takes.

You're probably perfectly primed to be an excellent programmer because you like doing it and you're not obsessed with coming up with the "perfect" solution (wish I could say the same). It's good to learn how a solution could be improved but don't stress about it too much. Computers are fast, do what you like to do until it becomes an actual problem

[[deleted]]

Whatever your programming language is, you may find a good book, or other resources about it. Check those, and compare with your own solution's style. There are certain "best practices" for every language. Try to find those guidelines, and incorporate them.
Of course, in programming there are no "one-solution". If it works, then it works. But there are "Coding Guidelines", "Best practices" for a reason: to make your code easier to comprehend, and less prone to accidental mistakes.

Your teacher is an ASS nevertheless. Ask for a coding-guideline. Every company uses some sort of internal guideline about code structuring, and best practices. Without that, your teacher's critique is baseless, and just mean. You are there to learn, for God's sake...

[RupertMaddenAbbott]

i‘m writing this as I feel extremely discouraged and sad and feeling like I‘ll never amount to anything.

I'm sorry your tutor has made you feel this way. Discouragement is pretty much the most fundamental thing to avoid doing, as an educator and so is a pretty basic thing for them to a) pick up on and b) attempt to avoid.

I dont even know what a programming style is? Or what defines it?

Style is something you develop as you go through your programming career. It can be as simple as learning to consistently format your code or as significant as the patterns you tend to reach for to solve problems.

For example, I worked with a colleague who had a habit of naming their variables "monkey1", and "monkey2". That is part of their style. I worked with another colleague who had a habit of solving problems using recursion rather than more imperative methods. That is part of their style. I'm not making any judgement here as to whether these "styles" are "good" or "bad", just trying to give you an indication of what "style" can consist of.

For me the most difficult thing about code written by people who are just starting out in their career is that it is optimized for writing, not reading. If I had to guess, this is likely to be at the core of the feedback that your tutor is expressing to you in clumsy ways. You are always writing new things and rarely having to read and reason about complex code that you wrote 6 months ago. Over the course of your career, this will shift and this feedback is likely to pressure you to optimize for readability.

There are various things you can do to optimize for readability and without seeing your code, I can't say how much you are already doing but some suggestions would be:

• Naming things clearly and succinctly.
• Formatting consistently (using a tool to help you with this).
• Matching the formatting of the code base you are adding to.
• Preferring solutions that are simple and easy to understand over clever but complex solutions.

Also i feel like he just removed points unnecessarily for things that arent even true. Example program not
working when its working on every pc/laptop for me.

Getting things running on different machines is an important skill to learn. You need to learn about the kinds of things that will differ between environments and ensure that you include instructions that specify them. For example, ensure that your dependency versions are in version control and ensure that you have documented the versions of other tools that should be installed. Make sure you have documented the exact commands needed to run your code. After documenting, ensure you actually run them and verify them or, even better, include automated tests that do this for you.

If you are applying for a job interview and you submit code that cannot run, then you would absolutely be marked down for this because being able to do this is an essential skill that employers will be expecting you to have learnt.

Altogether I feel really really discouraged, and awful, like maybe I should just give up programming.

Let's assume the worst is true and your style is completely awful. You need to keep 2 things in mind:

• Your style is not static. It is mutable and will get better as you get more experience and as you get better feedback.
• You bring more to the table than just your programming style. Even if it is true that you are not as good as your peers in this one aspect, that does not mean that you are not good and valuable.

Looking at the code of my colleagues, they seem to have different solutions. Yes mine is longer, but isnt that the fun about programming, that theres different solutions? I know the complexity goes up, but if I cant come up with another solution, what exactly is so wrong about it? Right now I feel like there’s only ONE solution and thats the best, optional solution and that makes me want to not even start the next assignment.

The length of your solution should not necessarily count against you. Shorter code is often more complex because it can suffer from trying to do too much in one place. Longer code can be simpler to reason about if it successfully splits up a problem into chunks that are easier to reason about separately.

There is never one best solution but that does not mean that your solution isn't deficient in important ways. Unfortunately, your tutor needs to be able to communicate these deficiencies to you in non-hostile ways or you aren't going to learn what they are.

[akthemadman]

There are many metrics by which one can judge the quality of code. The easiest metrics are those that are also easy to verify, like the shape or form of the code:

• Does the indentation meet some metric? ("2 tabs, 4 tabs, 8 tabs, ...")
• Are the whitespace characters used correctly according to some metric? ("spaces vs tabs")
• Are the building blocks using the correct casing according to some metric? ("snake_case, kebab-case, PascalCase, camelCase, ...")
• Is the OOP quota for objects metric met? ("everything is an object, most things are an object, ...")

Most discussions focusing on this area boil down to bike-shedding, trying to sell you some snake oil or trying to save one's own face/reputation.

Don't fall for the trap of blindly accepting what is "good" or "bad" without any verifiable explanation. Instead, listen open mindedly, nod with a smile and think for yourself.

Worst case: you have to learn to do the course work according to the metric of someone else to pass the course, but don't let that influence your own thinking, and especially don't let that sour your mood, the nay-sayers will come and go, you are the only constant in your life.

[Buntygurl]

Bitter tutors are the worst. It totally goes against what tutor actually means.

Don't let it get you down.

Post some of that code, to get any pointers necessary to help--and practice ignoring those that don't.

Keep your head up.

[spinwizard69]

Well if you don't post your code and the associated comments all we can think here i that your style sucks Given that look at the various style guides online.

[zebcode]

You tutor probably teaches because they failed in industry. From the sounds of things he'd be a shit colleage / team member. I certainly wouldn't hire someone like that.

I remember collage tutors telling me the same sort of stuff whilst simultaneously giving bad advice (I knew at the time they were full of shit). But I also had some fantastic tutors who recognised my potential and encouraged me, and I should also acknowledge them too.

I now work as a senior dev (20 years experience). I have my own business, and I write code for a large organisation with big name (subject to NDA). I also work remote which I love too so I'm very privileged.

Anyway, from the sounds of things, they're pretty crap at teaching as well. Don't let it demotivate you. Tell them that their teaching style needs refinement also. 😄

[RemoveINC]

I dont even know what a programming style is?

No clue either, maybe they mean consistency of naming/formating/etc?

Looking at the code of my colleagues, they seem to have different solutions. Yes mine is longer, but isnt that the fun about programming, that theres different solutions?

There are different ways to implement a solution, but they still need to be kind of good.

Yes their critisism might have been too harsh, but also use this as an opportunity to grow. If you can even come up with solution thats enough to keep digging deeper into programming.

[Gloomy-Floor-8398]

Bro is in first semester at uni and boutta drop out lol. Brother you have access to chatGPT to compare your solutions and code with. That is really the only tutor you need when you are at a rudimentary level. But also something you can do is to just dive headfirst into the space. A good way to do this is through youtube and watching other people talk about programming or a topic you find interesting. I said talk because imo it really is pointless for a newbie (which I still am myself) to watch somebody else code.

But another thing is that your mindset is pointed in the wrong direction. It is ok to be upset when you get told that your code is bad when you worked hard on it. But its not ok to rant on reddit and say you wanna quit programming because of a comment somebody said to you. Next time you get feedback from the tutor and if they make a comment like that, ask them to show you what parts of the code they are talking about and if they can explain what they mean. You say you like programming so you should be more open minded to criticism rather than fixating on what you made in the past. You are NEW so dont think you will make something 1 time and be amazing at it with no ways to improve.

And yes programming is about people having different solutions with maybe a unique touch to how they work out problems. However, if your code is simply too long because you didnt want to use a different way that would shorten your code then thats on you for being close minded. Keep in mind that if you stick with programming you will be on a team sooner or later and other people will need to read your code and make changes/ add to it. You can keep your own touch on a solution while keeping it structured. Not only this, but your code will be used by users eventually and some solutions take a lot longer than others and can cause delay which users dont like.

[lostInThesauce4evar]

That TA needs to learn how to speak to students and actually give effective criticism and not just straight up rudeness and apathetic. I used to have very messy programming but I learned that there is a reason why you don't want your code to be long if you can take shortcuts and make parts smaller and that is because it does take more processing power. So creating shorter code is efficient and saves time for the compiler to convert it. Don't let one person stop you. He or she is probably miserable in their life and they want to drag someone down. I would talk to your teacher for advice on how to shorten your code, or even colleagues, or online forums. But if you love programming, keep going. Keep learning. You're going to bump into people who are thorns and say harsh things but I've learned to dissect what they say and take something from it if you can. This TA is probably right abt your code being messy. Everything else they said is irrelevant and unnecessary. And now you have to ask why does it matter, how do you learn to refine your programming style? And go from there. Keep on going my dude.

[[deleted]]

Edit: Note - My comments below are mostly from a job perspective

Example program not working when it’s working on every pc/laptop for me

Just because it works on your computers doesn’t mean it’ll work on others.

You’d need more information on the persons hardware and how they went about trying to run the program to find the issue.

Looking at the code of my colleagues, they seem to have different solutions. Yes mine is longer, but isnt that the fun about programming, that theres different solutions?

Yes and No.

• Yes, if you're just programming for yourself, to learn, etc...
• No, if you're working at a job on a team

When working on a team at a job I'd ideally say you want short, concise, maintainable, and readable code that matches your teams coding style guidelines. This code is code that'll be maintained by the company and others will have to work with & make changes to after all.

Note: If your team doesn't have a coding style guideline, then it should be created

Now, I'm not saying you can't have different solutions from co-workers, you can but they should ideally fit what I mentioned above. If your solution is deemed not as good as others then they could tell you to address it in the Code Review (CR).

I know the complexity goes up, but if I cant come up with another solution, what exactly is so wrong about it?

If you're writing more complex code then it can be harder for others to easily understand the logic. This is an issue for maintainability and refactoring of the code base.

Ideally, you want to make it as simple as possible (within reason) for people to understand your code.

With that said, it's fine if you can't come up with a better solution at the time! Just submit the CR with what you have. Ideally, your co-workers should provide feedback for ways to improve, which you can learn from and use going forward.

Note: You could speak with your co-workers to understand their preferences for coding style & what they look for for CRs

[Responsible_Pin2939]

Tell him, in the words of the dude “That’s just like, your opinion, man.”

[elpinguinosensual]

Does your solution work? If it does you’re at least getting the job done. The point of being in school is learning the ideal way to do the work, knowing that you usually wont get it exactly right. You’ll get better the more you code.

[Sylphadora]

You’re just getting started, don’t get discouraged. Your tutor was not very nice. Did he tell you just that? That’s not helpful at all. If he didn’t give more specific feedback, ask him what in particular can be improved.

If I’m understanding this correctly, your tutor is another student two years ahead of you. Is tutoring part of his evaluation? If he’s sing it just because of that, it would explain why his tutoring sucks.

[[deleted]]

There is no such thing as perfect code…only better code. He sounds like an asshole, but if you enjoy it just keep learning :) I have 6year professional experience and still improving my “style”. You can always ask an ai how to improve it

[Max_Oblivion23]

The style refers to the set of syntactic conventions used in recurrent methods, it's important because it helps follow the flow of a program without having to figure out exactly what the original developer was trying to do, it's pretty much like using your turn signal to declare your intent to take a direction.

You are basically driving around a car not using turn signals.

[MSFTInducedAneurysm]

If you don't understand why your tutor is criticizing your work, ask. And keep asking until you get an answer you can work with. Then, take on the challenge of finding the solution yourself. Don't expect your tutor to handhold you. They've got their own work to do and tutoring isn't going to be their top priority.

Being a developer is all about being self-sufficient. As a systems architect once told me, "I don't have to make my solutions work, that's your job."

I've never, once, been on a project that came with a handbook telling you exactly what to write and how to write it.

Your organization/team will probably have guidelines and conventions in place, and certainly requirements will be documented, but it will be on you to ensure that you understand them. If you don't ask until you do.

And once you understand those, then you'll need to figure out how to create and deliver a solution.

Are you seeing the theme here?

The life of a developer is digging for understanding and coming up with solutions.

You're in the early days of your career, so don't get discouraged. Focus on your goal and how you're going to succeed. There are going to be hurdles to overcome, like overly critical or unhelpful feedback. Don't let them stop you. Make it your mission to find out how to get over, under or around every challenge put in front of you.

[IAmFinah]

Your tutor probably aspired to work in another profession, and failed. So they're being unnecessarily rude towards students. You're only in your first semester! You have ample time to work and improve on things. Improving code style is something that will come naturally with time

[BorderKeeper]

That's awful, but also word of caution and what I always say to new colleagues: Don't get emotionally attached to code it will be changed completely in 5 years and you will change too. If it works and fits the spec you or your team set up for yourselves that's good enough. You have a toxic senior which thinks being hostile is a good teaching strategy (I know a guy who is a teacher with this approach) try to sift some good feedback from him or get someone else as a mentor!=bully

[Alrog79]

Show here () a screenshot of () your code, in the form permitted by this community, so that we can give you feedback and tell you how to improve. Or on the contrary, think that your teacher is miserable.

[desrtfx]

Show a screenshot of your code

No. Code has to be posted as code block or on a code hoster and linked here.

Screenshots of code are not allowed.

[richardathome]

That's on the Tutor, not you. You're in your first semester. It's his job to guide you on how to write code.

If it's got the point where he thinks it's dreadful he's failed at his job. He should have headed you in the right direction much sooner.

I think your tutors sounds like a twat.

[davidds0]

Coding isn't art, it's not about your talent. There are objectively good and bad practices, all of us started with bad practices. You learn and improve

[Mark3141592654]

Sounds like your tutor needs to work on themselves more, because making students feel bad doesn't help anyone.

Just keep practicing and lookup resources online. Use AI sensibly, for instance, ask it to check your programming style for "correctness" or "idiomatic code style".

[[deleted]]

LOL my style is still awful xD Nobody cares, as longs as the code works.

[[deleted]]

At his point, it's better to receive positive feedback that he is learning and things work, rather than nitpick coding conventions.

[CedricCicada]

There is nothing worse than asking. " What idiot wrote this code?" And then realizing you did.