Is writing code out still considered an algorithmic representation?

I just lost 50% of my answer on a test because I wrote the code out instead of an algorithm on my midterm, bumping me from an A to a C. Is writing code out still considered an algorithmic representation?

Wikipedia: Algorithm Representation (since programming style is pretty much consensus-based)

EDIT: Ok, so let me make a few points clear:

The test asked for pseudo-code, which we never really "defined" in class; we just wrote out English for our algorithms.
It's a Java class, and wrote out the entire solution in a Java method, along with comments. All of this was hand-written, and took longer to write out than pseudo-code. I thought it would be more clear.
I normally wouldn't make an issue about such things, but it's the difference between an A and a C, and I have a scholarship riding on my exams.
Finally, I'm making this post for two reasons:

4.1 I want to show what the modern programming community thinks about pseudo-code and algorithmic representation.

4.2 I want to know what's acceptable in the "real world"; I've been programming for some time, but I want to be able to contribute to open-source projects soon, and I don't want to step on anyone's toes. (Although I'm pretty sure that this topic has little chance of coming up in the real world).

Again, thanks for any help/advice.

Solution

You may want to give an example. If your code focuses too much on language specifics that are not part of the algorithm, then Understandably, it could be said you had non-algorithm mixed with your algorithm, resulting in an incorrect result.

I Feel for the reasoning, the whole point of learning is to show you understand the concept, not to bend over and tick all the right boxes.

A computer can be taught to pass university, but a computer cant be yet taught to actually think for itself and apply knowledge.

Eat and regurgitate mentality is why I never graduated.

With respect to your recent comment, its important to realise pseudocode is undefined. There are generally reused terms in it, but its not a strict language any more than english is ( otherwise it would be a programming language, which could be parsed and executed verbatim )

The importance of pseudocode is to flesh out the logic part of the system and not have to worry overly about the syntax beyond 'it makes sense'

Often this can make the pseudocode both more terse and more understandable.

Pseudocode also doesn't rely on the reader having an understanding of the 'magic syntax' in the language in order to process it, all they need to understand is the terms used.

If you were to give the average person an algorithm in perl for example, most people would just die from horror because they don't see past the screeds of line noise.

While:

sub foo { 
   my @args = @_ ; 
   my( $a, $b )=(@args[0],@args[1]); 
   for( @{ $a } ){
       $b .= $_ ; 
       s/id//g; 
   }
   return [$b,$a];
}

may make some coherent sence to somebody versed in perl, to the average code reader all they get is a "what the hell did you just say" response. Documenting it doesn't help a lot either.

| there is a subroute foo which can take a list of strings, and a default string, 
\-  which then iterates all items in  that list, 
| \-  and for each item in that list 
|     1. appends the contents of that item to the end of the default string
|     2. removes all instances of the string "id" in that item
| 
 \ and returns a list, which contains 
    1. the concatentated default string 
    2. the modified input list

Suddenly it becomes less ambiguous and a greater percentage of peoples can understand it.

So possibly, half the exercise with writing the algorithm is an exercise in "Not only do you have to prove you understand it, you also have to prove you can explain your reasoning to others whom know nothing of the problem" , which is a vital ability you need. If you can't communicate what you have done, nobody can use it.

_{there's also this nasty little problem with code, that doesn't exist in an algorithm, and that is the code may look right, but may not do what you think it does, and if it doesn't do it right, and you don't realise, people reading the code reverse engineering it will foul it up and copy a broken algorithm. not good. the algorithm in human form better translates 'this is what i want it do do'}