omg, just wrote a huge long post about not getting why this bool kept always returning true, and then I happened to see that one of my if() statements was using the assign = operator instead of ==.

Why would that not throw a compiler error?

I demand digital blood!

Some compilers probably will for some languages.

Probably you are using a scripting language like JavaScript?

In most C-style languages, an assignment operation also produces a value. This is occasionally mildly useful in constructs like this:

Or in chained assignments:

For the amount of grief it causes, IDK if it's worth it, but here we are. Nobody wants to make an alteration to C-style languages that might break existing code.

The problem in weakly-typed languages like JavaScript is that everything is "truthy", so things like 3 or 'banana' are true. (The only things that are not true in JavaScript are false, 0, '', null, NaN and undefined). Therefore the value produced by the assignment is silently cast to true.

In C#, which is mostly what I write in, something like this will not compile:

But this will, because the assignment produces the desired bool type:

But it does throw this compiler warning:

I also have the Resharper addon for Visual Studio, which underlines that "x = y" in the IDE and warns me about it when I mouseover.

Its c++ using Microsoft Visual Basic 2013

Yeah, C++ allows implicit conversions between, for example, int and bool. Because lol C++. They finally got around to introducing a way to fix it (sort of) in C++11, like 28 years after the language came out.

A 'good practice' (that I've never actually used) is to reverse the way you usually do equality comparison so that the constant is first.

So if you wanted:

You would switch it to:

Because then if you messed up and forgot an = sign, the statement "3 = foo" is invalid and will throw an error.

An even better practice would be avoiding languages that set traps for you to fall into.

That seems more like an impossible practice.

Also like a very difficult way to get a degree or a job.

Getting a degree is one thing and C++ is a reasonable language for that. I would not recommend anyone but a masochist actually get a job writing C++

My point was more that C++ isn't the only language that has 'traps' or even this particular trap. Off the top of my head I believe Ruby/Java/JS let you use an assignment operator incorrectly in a comparison.

Oh, that's quite brilliant! I'll have to remember that, thank you!

Is it normal to see it that way? I assume I'll be using c++ for the majority of my time in school over the next 18 months or so.

why do comp sci programs teach people to program in languages that are harder to use? tradition? seems dumb.

weed out all the people who aren't willing to smash their heads against the wall for a couple of years for the chance of a better career?

Our small class isn't going terribly well. I nearly aced our last exam, but we had as many As as we did Fs. (over a third of the class)

I'm glad I'm doing well, but I always feel like I have roughly no clue what's going on. I think of it a lot like playing StarCraft. In SC, says as terran, I like to wait to wipe out an enemy until I have like 5 nukes and the resource cap of units. I don't want to win, I want to deftly destroy my opponents with a staggering display of overpower. In other words, I like to be extremely over-prepared. And I don't feel that way at all, no matter how much I keep reading and rereading, doing practice work, self-tests, assignments, labs, projects, etc.

Our teacher, who's been doing CS stuff for a couple decades, just writes this perfect, concise code with no superfluous text. Really can't wait till I get to that point.

/rant

Yoda conditions ftw!

Sometimes the concepts are easier to teach in that language? Sometimes the language is quirky and weird which makes it interesting.

Either way, you have to realize that computer science isn't about learning how to program. Maybe moreso for the lower division classes, but at the end of the day, once you go through all those weird abstract languages, I feel like it should be easy to pick up any trendy language and learn.

It varies but frequently it's that the person responsible for writing the course either a) just uses what they know or b) is convinced that it's IMPORTANT for noobs to learn various esoteric concepts made explicit in the language. Academic computer scientists generally think it's important for people to know how computers work at a basic level, for some reason.

I had a horrible CS course. We started out learning to use a language probably nobody here has heard of, called Ada. Mercifully, we switched to Java later on. I was doing second year CS in the year 2000 and had a one-semester subject called "Database and Information Systems". We spent the first entire term, I **** you not, learning COBOL. Because the lecturer, who must have talked like 10 times about how he did his Ph. D. on punch cards, thought "COBOL is a good way to learn database fundamentals". Anyone who thinks COBOL is a better way to learn database fundamentals than SQL isn't competent to teach CS, it's really that simple.

I remember we spent time learning about Turing machines and learning assembly language and **** as well. Nothing could be less relevant to modern software engineering. We'd have been better off with a subject teaching us how to use various models of coffee machines.

I definitely think C++ is a suboptimal choice for teaching noobs. Why would you turn beginners loose on a language with no memory management? OH BUT IT TEACHES YOU THE FUNDAMENTALS OF HOW MEMORY ALLOCATION WORKS. Herpitty derp.

It's a debated topic. The counter-argument is that it makes your code less readable.

Code readability trumps almost everything else for me. For instance, except in special cases, it trumps performance. CPU cycles are cheap these days. Software engineering is not.

If everyone coded their equality checks Yoda-style in C++ then it would be OK - just another syntactic feature of the language to learn. But they don't, and writing in a way that other people will understand is very important.

a guy I used to work with (one of the best programmers I have worked with actually) used that style in java. Mainly with null checks. It took a little bit to get used to but in the vast majority of cases the if blocks are short enough it didn't really feel less readable to me, past the initial novelty.

I'm not sure I have a point. I agree with you that generally readability trumps all, it just doesn't seem to me like (variableName == null) is so much less readable than (null == variableName) after like 5 minutes. ymmv? I don't actually use the style myself

I wouldn't mind personally but a lot of people find it important to have code that follows the way they naturally think. "Check if thing x is null" is a coherent thought, "check if null is thing x" is not. Witness the growing popularity of fluent APIs to see how important code that comports with natural thought processes is to people.

For me, I don't care about that, but if things are incorrectly named it really messes with my thinking. If you created a 2+2 app and had a class called "Post" that actually represented whole threads, it would seriously affect my productivity if I had to work on the app. Everyone has their annoyances that derail their thinking, its best to write code that is as clearly expressive as possible.

+1.

Also, "readable code" depends on a lot of factors and I'd argue that "readable code" for a student is very different than readable code for a professional. When you're learning it can be useful to have 'training wheel' type tips like the yoda condition to make your life easier.

In fact I just finished a code review where I asked our intern to delete a bunch of comments. They were useful to him, but they were explaining common practices and Java functionality that anybody with experience wouldn't need explained and so they were just adding a lot of noise to the file.

Commenting code is a sickness. I write comments whenever I'm doing anything particularly complicated, or to explain why I've done something weird as a workaround. Aside from that I hope my code speaks for itself. When was the last time you read a comment and were like "thank God for that comment, I'd never have understood this code otherwise"?

I have the misfortune to spend a bunch of my time improving an app that was originally written by a completely incompetent offshore team and I delete all their comments on sight without reading them. Either they're comments like "A method to save the Derp" on a method called SaveDerp(), or, even worse, they're comments like "A method to save the Derp" on a method called SavePineapples() that has nothing to do with Derp.

I'm lucky and work with a small group of really talented people - so our code comments are usually pretty useful.

So for example, we deal with a bunch of distributed processing and so a lot of times a comment will be explaining what assumptions are safe to make and what assumptions are not safe to make at a particular point in time.

This drives me crazy.

One thing that might actually merit its own thread is how quickly good software engineering degenerates into cargo-cult programming. (I'm reminded of this by how commenting code is actually good but in the hands of people who don't know what they're doing just makes things worse and less readable).

In this app that I work on that was written by an offshore team, there were some signs that someone in the team had read an article on dependency injection. Some stuff was divided off into Repositories, Services and so on in DI-ish fashion. The thing is, actual DI essentials (like programming to interfaces, a composition root, etc) were entirely absent, and even the Repository/Service thing was inconsistently applied. I stripped all that stuff out and converted it to direct calls, because many times there were 5 different methods doing the same thing and I would have to fight through 18 layers of abstraction before confirming this was the case. My strategy is: Make concrete, unify/simplify, then maybe we can talk abstraction.