|
Interesting, yet what you said makes sense about deadlines and stuff... Unfortunately the real world doesn't always allow for nicely-put-together stuff... In any profession really.
Well, I've been reading several good software engineering books lately and was just looking for more real-world examples besides the simplified stuff in the book. Surely someone must be able to write what they call "clean code", no?
If not, what exactly are most employers judging you on? If they don't really care about the code quality, then what are they looking for in the interview?
I've done a few small projects/freelance jobs but I have not yet formally worked for an employer.
|
|
|
|
|
TheOnlyRealTodd wrote: If not, what exactly are most employers judging you on? If they don't really care about the code quality, then what are they looking for in the interview?
Often enough the interviews have little to nothing to do with the actual work. Some were so creative when it came to avoiding standards that you ended up doing the opposite of what all experience or common sense would command.
In such a place it's very important to claim every (rare) success for yourself while pushing the blame for the (frequent) failures on somebody else, independently of what you worked on or not. Such places are like sinking ships, only that everybody will fight for the best positions, not for a seat in a lifeboat. If you end up in such a madhose, do yourself a favor and get out of there as fast as you can.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
What employers look for is varied, depending on a lot of things like the size of the organization or the management style
The other day I was talking to one of the HR guys (a most un-catbert like individual) and he said that what they mainly want to know in interviews is whether the candidate can use prior knowledge and experience to do his job
So say they want someone to maintain their ASP.NET website. The ideal candidate would already have several years experience in doing just that, but failing that (which is usually the case), they would try to get someone with at least some experience in some .NET technology. Hiring a Linux kernel developer is not going to be a good idea here.
Another thing is whether they will fit in with the team. Some rock star programmer is not going to cut it in a large corporate environment, they would rather go for someone with less ability who works well with the team than a super coder who is socially inept and pisses everyone off.
This would probably be less of an issue in startups, where they do want people who are super performers at the expense of social skills.
Code quality is something that they won't find out in interviews. Maybe they look at your github repo or something, but there aren't nearly enough people who even have one in the first place. Or maybe they throw out the duds during the first few weeks at work, not that I have seen it happen very often.
The cynic in me says that employers want people who work long hours for peanuts and not raise a stink about it, but I guess that would be a shortsighted policy.
|
|
|
|
|
California 90025 wrote: there is no objectively "well written" software
It's often easier to spot badly written software and there seems to be some consensus on what that is. Just last week I had to work with some SQL code that was written like SELECT somefields FROM table1, table2 WHERE table1.id = table2.table1_id. Now that's fine code... If you live in the 80's before proper joins were invented. I even found a where ... ( +) (it was Oracle) that I couldn't even read. Apparently the ( +) is an outer join from before outer joins were invented.
You may be thinking it was an old project and people didn't know better at the time, but actually that code was written two weeks ago 
Ask a million serious SQL developers what they think of this code and I think (hope) at least 99% would agree that it was actually bad code.
Now replace it with proper joins, ask those same developers again and now your developers will be squabbling about casing, indentation and even the order in which you write your where-clause 
|
|
|
|
|
California 90025 wrote: Another thing is there is no objectively "well written" software. When you go out into the industry (I'm assuming you still haven't or are new to it), you will come across all kinds of a-holes who find fault with every f-ing thing no matter how well it's written. I think there was someone who posted here about how the boss rejected his code because the others were too incompetent to understand it.
I've wondered about this, as someone who has not yet worked at a shop. I hear a lot about how there really isn't any ideal code and "as long as it works, it's fine" but at the same time, there are highly acclaimed books and articles that suggest that there is in fact a "right way" to write code, such as Code Complete by Steve McConnell, and that Clean Code book by Uncle Bob.
Ultimately, of course this is just their suggestions, but nonetheless, they seem to be well-accepted suggestions. Though, I believe every word you say about people picking apart your code no matter what, I may not have worked at a shop yet, but I've been working with people for a long time, lol.
|
|
|
|
|
California 90025 wrote: California 90025
I assume this means you're around WeHo? I'm in Studio City.
Jeremy Falcon
|
|
|
|
|
You'll often learn more from looking at poorly written code, because you're fixing it in your head, and coming up with new ideas -- so the worse the code, the better.
Is the windows 10 source code available?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
You're a cruel man! 
I suspect that Win10 was actually pretty well written - the problem is that it's badly designed. It fits an "ivory tower" ideal rather than the real world, and that's where the problems start. Then patches get chucked in to make the ideal sort-of-work in the real world (despite the real world's strenuous objections) and that makes the situation worse.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Whoa!
Are you saying that the ribbon and baby blocks are "ideal world"?
Only smoke the wool from the black or white sheep, Griff. Leave the green ones be.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Nope, they're solidly Ivory Tower! 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Writing "Clean Code" is a wide field. My point is, that is a design problem and has to do with software architecture. So reading some clean code wont help you anyway.
Maybe this book about clean code helps you developing such skills.
"Clean Code" isnt for itself but
- avoid bugs with sound and state of the art principles and
- mostly maintainability. (my main point, because I use code with 10+ years)
By that the coding speed increases and the cost of development are sinking. 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
This may attract hoots of derision but actually a lot of the MS open-sourced code is quite high quality. Look at (for example) Entity Framework or Orleans on GitHub?
|
|
|
|
|
The problem with that is a lot of it is subjectivity. For instance...
var x = (y == 5) ? 0 : 1;
var x;
if(y == 5) {
x = 0;
} else {
x = 1;
}
var x;
if(y == 5)
{
x = 0;
}
else
{
x = 1;
}
var x;
if(y == 5)
x = 0;
else
x = 1;
And who's really right or wrong?
Jeremy Falcon
|
|
|
|
|
Jeremy Falcon wrote: And who's really right or wrong?
COBOL's right, of course:
IF y = 5 THEN
x = 0
ELSE
x = 1
END-IF.
(Whatever you do, don't forget the fullstop)
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: COBOL
How DARE you mention that... that... THING here in the Lounge! To the Soapbox with you!
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Nothing wrong with COBOL
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
The third option is correct.
Jeremy Falcon wrote: And who's really right or wrong?
I am.
|
|
|
|
|
your first example is not the same as the others:-
?: is NOT if-then-else...
var x = (y == 0) ? 0 : z / y;
var x;
if (y == 0) x = 0; else x = z / y;
If it were easy then anybody could do it.
Wait, .... what!
|
|
|
|
|
I'm not sure if this is sarcasm or not. 
Jeremy Falcon
|
|
|
|
|
To me, studying what good code looks like and the best practices thereof has more value than looking at somebody else's code. I consider the reference article here[^] to be of more value than a bunch of code.
If you want to lose your mind, read the source for the stl libraries.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
As a recommendation I'd always suggest having a look at the GitHub repo for Doom & Doom3 (from John Carmack at id Software). Doom written in C and Doom3 in predominantly C++.
GitHub - id-Software/DOOM: DOOM Open Source Release[^]
GitHub - id-Software/DOOM-3-BFG: Doom 3 BFG Edition[^]
Although a lot of the work is in game development and graphics (and in C), I found it useful to look at how it highlights good project and code layout.
Like people have said already in this thread, I wouldn't look at the code to "learn how to write code" but rather to learn what good "coding practices" result in. Keep in mind some of this code has been cleaned up before publishing on GitHub.
K
|
|
|
|
|
Thank you!
Yeah, it seems writing good code stems from both design and good coding practices...
Currently, I am reading the books Code Complete and Clean Code by Uncle Bob. Code Complete seems to focus more on the design aspect stuff, and Clean Code seems to focus more on the actual code-writing practices.
However, Simply looking at projects gives me at least some insight into the coders' styles out there and what type of code I will run into out there.
|
|
|
|
|
|
First, reading lots of code is the RIGHT approach. Kudos. To put it into reading/writing books, I would say that someone who actually writes a (decent) book has read THOUSANDS of books first. It just makes sense.
Second, you can learn from ANY code. Even if you learn "Ouch. That's terrible". B-Movies exist. They remind us what works in good movies, and what doesn't work.
Third, consider reading the (source code for) well understood concepts. Compilers (GCC?). Compiler theory is pretty stable. the concepts of cross compilers, linkers, etc. are all well understood. Optimizers, for example, re-teach indirection (converting code to pseudo assembler, optimizing that, then generating the assembler already optimized). Allowing the optimizer to be shared!
Finally, a discussion about engineering... Most people think that engineering is about perfection. It is actually about making things Good Enough. Optimizing the 3 corners of the triangle of (Fast, Right and Cheap). You can only optimize 2 of the 3, and you agree to sacrifice the third. You can optimize only 1, and sacrifice the other 2.
I learned about this from an engineer neighbor who was designing a factory floor with equipment mounting technology. His junior engineer was calculating the EXACT bolt sizes required based on the machine and the other variables. He made him go back and find the Most Common Denominator to reduce installation issues and mistakes.
In words developers can understand. I have a compiler to sell you. It's NEW warnings are guaranteed to reduce the number of bugs by 10% in your code. It costs $1 Million per seat. Interested?
I hope not!
So, keep reading code.
Then find useful code, like Notpad++, and work on compiling it and testing it.
Then find a list of bugs for that Product and start fixing them and testing your solutions.
You should quickly learn a couple of things. Like having a set of automated tests makes you feel safer to make changes and know if you actually broke something.
I would finish it off with. BREAK the software. Find what tests fail, and how. It's insightful!
|
|
|
|
|
You are asking a FANTASTIC question, and you should be HIGHLY commended for your EXEMPLARY judgement and acumen for seeking such recommendations. (Of course, I can say that because I asked the same question myself about six months ago!  )
Among the many helpful replies that I got in that thread, the one from BillWoodruff[^] was the most extensive and helpful.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
