Kerala Plus Two Computer Science (DHSE) common mistakes
Kerala Plus Two Computer Science (DHSE) · Understand the traps and how to avoid them.
Writing `char *p = "Hello";` and then attempting `p[0] = 'h';` or `*p = 'h';` in a pointer program, expecting the string to be editable.
Students learn that a pointer to char can be used like a string and treat the string literal as a normal array. They do not realise a string literal is stored in read-only memory, so the write is undefined behaviour and typically crashes at run time.
What to do instead
Declare writable text as an array: char s[] = "Hello"; s[0] = 'h';. Use const char *p = "Hello"; when only reading is intended, so the compiler rejects the assignment. Practise stating, for each declaration, whether the pointer points to an array or to a literal.
Using `=` instead of `==` inside an `if` condition, or writing `if (a = b)` in a loop/condition and not noticing the logic silently changes.
Both are valid C++ expressions, so the compiler accepts them without error; the assignment yields a value that is tested for truth. Beginners read the line as a comparison because that is what they intended.
What to do instead
Adopt the habit of compiling with warnings enabled (-Wall) and reading every warning. Write comparisons with the constant on the left where possible (if (0 == x)), and after writing any condition, read it aloud as 'is equal to' to check the operator.
Confusing pointer arithmetic with value arithmetic: writing `*p++` when `(*p)++` was meant, or assuming `p + 1` moves one byte rather than one element.
Operator precedence (++ binds tighter than *) and the scaling of pointer arithmetic by the size of the pointed-to type are both invisible in the source text, so the two forms look interchangeable.
What to do instead
Memorise the precedence rule and use parentheses for clarity: (*p)++ increments the pointed-to value, *p++ increments the pointer. When tracing, write the address and the value in two separate columns and step through with a small array of ints.
In array programs, writing a loop as `for (i = 0; i <= n; i++)` for an array of n elements, or starting at 1, and then reporting a garbage last element or a crash.
Everyday counting starts at 1 and 'up to n' feels inclusive, while C++ arrays are indexed 0 to n-1. The off-by-one only shows up when the program is actually run or traced.
What to do instead
Before coding, write the valid index range as a comment (// indices 0..n-1). Use the fixed pattern for (int i = 0; i < n; i++) and, for a linear search, return -1 after the loop rather than inside it. Trace a three-element example by hand before submitting.
Describing stack operations with the wrong end: saying a queue removes from the top, or that a stack is FIFO, and then drawing the wrong output sequence for a push/pop trace.
The words 'top', 'front' and 'rear' are learned as vocabulary but not tied to a picture, and both structures are drawn as boxes in the textbook, so the diagrams blur together.
What to do instead
Anchor each structure to one physical image and one acronym: stack = pile of plates, LIFO, changes at TOP; queue = ticket line, FIFO, insert at REAR and delete at FRONT. For every trace question, redraw the structure after each operation instead of doing it mentally.
In a singly linked list, losing the rest of the list while inserting or deleting: writing `start = newnode;` without first setting `newnode->next = start`, or deleting a node without saving `temp->next` before `delete temp`.
The order of pointer assignments matters, but students write the lines in the order they think of them (create, link, move head) rather than the order that preserves the links.
What to do instead
Use a fixed sequence and say it aloud: for insertion at the front, (1) newnode->next = start, (2) start = newnode. For deletion, (1) temp = start, (2) start = start->next, (3) delete temp. Draw the boxes and arrows after each line.
Treating a class as if it were an object: writing `Student.roll = 5;` using the class name, or forgetting the terminating semicolon after a class definition's closing brace.
The class/object distinction is new vocabulary, and the class body looks like a function body, so the trailing semicolon is dropped; the class name reads like a variable name.
What to do instead
Remember the rule 'class is the blueprint, object is the house': you must declare Student s1; and then use s1.roll = 5;. Always write }; at the end of a class and compile immediately after writing the class skeleton, before adding members.
Writing a constructor that returns a value, or declaring it with a different name from the class, and then being unable to explain why the object was not initialised.
Constructors look like ordinary member functions, so the return type and naming rules feel optional; the compiler error or silent misbehaviour does not point at the cause.
What to do instead
State the three rules explicitly: same name as the class, no return type (not even void), called automatically at object creation. Practise writing a default constructor and a parameterised constructor for the same class and note that the parameterised one means you must pass arguments when declaring the object.
In SQL, using `WHERE` to filter groups (e.g. `SELECT dept, COUNT(*) FROM emp WHERE COUNT(*) > 2 GROUP BY dept`) or omitting `GROUP BY` while selecting a column with an aggregate.
WHERE and HAVING are both 'conditions' in everyday language, and the logical order of query execution (FROM, WHERE, GROUP BY, HAVING, SELECT) is rarely practised, so students place the aggregate filter in the wrong clause.
What to do instead
Memorise the execution order and the one-line rule: WHERE filters rows before grouping, HAVING filters groups after grouping. Rewrite any query that compares an aggregate to a number using HAVING, and always list non-aggregated selected columns in GROUP BY.
In HTML/CSS/JavaScript, mixing the three layers: putting layout in `<font>` or `align` attributes, using `onclick` handlers that call a function defined after the script has already run, or confusing `==` and `===` in JavaScript.
Older tutorials and textbook examples still use presentational HTML, and JavaScript's loose equality and hoisting are unfamiliar, so code that 'looks right' fails silently in the browser console.
What to do instead
Follow the separation rule: structure in HTML, presentation in CSS, behaviour in JavaScript. Use document.getElementById inside a DOMContentLoaded handler or place scripts at the end of <body>. Prefer === and check the browser console for the actual error before changing code.
In PHP, expecting form data to appear as `$_POST['name']` when the form used `method="get"`, or echoing user input straight into the page without escaping.
The superglobal name is tied to the form's method, but students copy a snippet without checking the form tag; output escaping is not visible in the source at all.
What to do instead
Match the superglobal to the form method deliberately: GET sends data in the URL and fills $_GET, POST fills $_POST. Use $_REQUEST only when you truly do not care. Always escape output with htmlspecialchars() and check with isset() before using a key.
Confusing IP addressing and protocol roles: calling an IP address a 'physical address', saying MAC addresses are assigned by the ISP, or claiming TCP is connectionless while UDP is reliable.
The layers are taught as lists of names, so the mapping between layer, address type and protocol property is memorised as separate facts rather than one consistent model.
What to do instead
Build a single table with columns layer, address/identifier, protocol, property (connection-oriented vs connectionless, reliable vs best-effort) and fill it from memory weekly. Anchor MAC as the burned-in hardware address used on the local link and IP as the logical, network-assigned address routed across networks.