473,836 Members | 2,187 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

C Syntax

Why is C syntax so uneasy on the eye?

In its day, was it _really_ designed by snobby programmers to scare away
potential "n00bs"? If so, and after 50+ years of programming research,
why are programming languages still being designed with C's syntax?

These questions drive me insane. Every waking minute...
Nov 14 '05
177 7127
> Delphi is Pascal with maybe a few bells and whistles.
Therefore, it's based on an older language than C, maybe that's why
it's a bit boring.


Pascal and C are of the same age almost. Pascal maybe 2-3 years older than
C, not more
Well, rephrasing Paul Graham, I should say "Don't wait until C will become as
clear as Python, use Python instead".


If you really think Python has clearer syntax than C, well, think twice.
One terrible fact is this indentation thing in Python to delimit code
blocks. One tab or space is left behind, and the whole thing is screwed.
To me, it's an unacceptable syntax issue.


Python programs are easier to read and understand, that's what I understand
as "clear". And I had never such problems as leaving behind tabs or spaces,
it's generally no problem with good text editor.
Nov 14 '05 #81
Dan Pop wrote:
In <84************ **************@ posting.google. com> ol*****@inspire .net.nz (Old Wolf) writes:

Da*****@cern. ch (Dan Pop) wrote:
None of the programming languages assigning semantics to indentation
has ever become mainstream. There must be a reason...


The language of makefiles?

Indentation per se is meaningless there. It's just that the language
syntax requires a TAB character as the first character on a line in
certain contexts.

Dan


Usually the Rule starts at the left margin and the Command is on the
next line indented with the TAB character. I always found this TAB a
nuisance because my editor puts spaces out when I press Tab key.

Imagine my joy upon reading that GNU make (if not others) also
allows separating Rule from Command with semicolon.

# Use GNU make to build an executable for testing GE.

cc=gcc
obj=ge.o main.o
exe=main.exe
opt=-W -Wall -ansi -pedantic -O2 -c

# Note that semicolon (not TAB) separates Rule from Command on a line.

$(exe) : $(obj) ; $(cc) -s $(obj) -o $(exe)
ge.o : ge.c ; $(cc) $(opt) ge.c
main.o : main.c ge.h ; $(cc) $(opt) main.c

--
Joe Wright mailto:jo****** **@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 14 '05 #82
In article <4t************ ********@comcas t.com>,
Joe Wright <jo********@com cast.net> wrote:
Imagine my joy upon reading that GNU make (if not others) also
allows separating Rule from Command with semicolon.


This is a standard make feature. In a way it is the fundamental
method to separate the dependency list from the commands. The
lines startong with TABs are just continuation lines for the commands.

--
Göran Larsson http://www.mitt-eget.com/
Nov 14 '05 #83
C# Learner <cs****@learner .here> writes:

|> Alan Balmer wrote:

|> > On Thu, 27 May 2004 04:36:24 +0100, C# Learner <cs****@learner .here>
|> > wrote:

|> [...]

|> > Forgive me if I'm wrong, but my impression is that you don't have
|> > a deep enough understanding of the C language, and indeed of
|> > programming languages in general, to appreciate the reasons for
|> > the syntax features you're commenting on.

|> I believe that I appreciate the reasons for these features. What I'm
|> saying is that I think that there are better (in terms of allowing
|> the user of the language to write readable code) alternatives that
|> could have been implemented instead.

|> > Take your original example of eliminating the deli meters around
|> > the conditional in an if statement. Think about what this would
|> > mean for compound conditions. Combine that with the Python-style
|> > blocking and then think about an if statement which tests for
|> > several conditions, requiring more than one line to write.

|> a) Valid C syntax:

|> if (foo &&
|> bar) {
|> foobar();
|> }

|> b) Similar code to the above but using my suggested syntax changes:

|> if foo &&
|> bar:
|> foobar();

|> Why wouldn't (b) be feasible here?

|> Everything from 'if' to ':' is considered the condition.

Even if there is a ?: operator in the conditional expression?

|> After the newline after ':', whitespace is required to form a code
|> block.

Let's see, you want to overload on whitespace?

|> > As you study and understand the language, you'll find that it's
|> > all nicely consistent, and that there are good reasons for most of
|> > the features which seem odd to you.

|> The only way in which they seem odd to me is that they make code
|> much less readable than it could be, in my opinion.

Things like C's declaration syntax make code less readable. But you
didn't mention that. The preprocessor can be really effective in making
code less readable too, but you didn't mention that either. And of
course, all those funny characters really made code less readable back
in the days when I had to work with an ISO 646 terminal -- in the German
variant.

But you seem to be attacking areas where C basically has no serious
problems. I personally prefer something like:

if expr then
stmt_list
else
stmt_list
endif

but the alternative used by C is pretty acceptable too. (And my
preference may have been conditioned by the ISO 646 terminals above.
Things like:

if ( expr ) ä
stmt_list
ü else ä
stmt_list
ü

are not particularly readable.)

|> Okay, if you don't agree with the 'if'..':' idea, then how about
|> changing the parentheses required for test conditions for a
|> different pair of characters? An ideal pair would be a pair that
|> isn't used elsewhere in the language, for readability's sake.

|> > One of the characteristics of C is terseness, and extra parens
|> > aren't required by the language for no reason.

|> My point is that a different construct could be substituted in each
|> case.

|> > Also, think about the fact that language inventors and
|> > implementers are, by and large, a pretty bright bunch. In general,
|> > they probably have more and wider experience in the field than you
|> > do, and some of them might even be as smart ;-)

Let's not get carried away. Language designers don't work in a vacuum,
and C is like it is for a variety of historical reasons.

|> So those who invented C's syntax are necessarily brighter than those
|> who invented, say, Python's syntax?

They were certainly working in a different context. I don't know
Python, so I can't say, but from the little you've shown, my impression
is that it is something that works well for quick hacks, but doesn't
scale well.

|> > Those features which have passed through to modern languages have
|> > done so for a reason.

|> I honestly wonder what that reason is.

They work.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Nov 14 '05 #84
Da*****@cern.ch (Dan Pop) writes:

|> In <c9**********@o ravannahka.hels inki.fi> Joona I Palaste
|> <pa*****@cc.hel sinki.fi> writes:

|> >Mark McIntyre <ma**********@s pamcop.net> scribbled the following:

|> >> Gonads. This is nothing more than a style thing. French people
|> >> put two spaces after a full stop. English people don't. Same
|> >> idea.

|> >I've seen plenty of English-speakers (at least USAns) write two
|> >spaces atfer a full stop.

|> It has nothing to do with the language. It's a common (albeit not
|> universal) typographic convention to leave more space after the
|> punctuation sign terminating a sentence then after punctuation signs
|> inside a sentence.

It is a common (albeit not universal) typographical convention in the
anglosaxon world. Look at a book printed in France or Germany.

Correctly typeset French uses three different spaces :

une espace fine insécable : about a fourth of a quad, no line break
allowed.
une espace mots insécable : about a third of a quad, no line break
allowed.
une espace justifiante : nominally about a third of a quad, but can be
stretched or shrunk, allows a line break.

Nothing larger for the end of a sentence.

|> Examine a few printed books carefully and you may notice it (it's
|> not twice as much, so it's not immediately obvious).

|> The only way to follow this convention in a plain text document is
|> by using two spaces instead of one. This is what I'm consistently
|> doing, no matter in which of the three languages I'm familiar with
|> I'm writing.

Then you're probably doing it wrong in two of them. Different
linguistic communities have different conventions. A larger space after
a sentence is definitly wrong in French or German, and I think it is
wrong in Italian. On the other hand, it would generally be considered
poor typesetting in English not to use it, although how much extra space
is debattable, and if the difference is small enough, the average reader
might miss it.

|> >Now the French, they put a space before an exclamation or question
|> >mark. Like this: "Regardez moi ! Je suis français !". What's
|> >with that, then?

|> Yet another bogus generalisation coming from Joona. Quoting from a
|> post from a French mailing list:

|> ton enfant ? quel age?

|> :-)

Doubtlessly a typo. Or simply incorrect use.

On the other hand, correct typographical use here is an espace fine
insécable, not a full space. Personally, I find the difference
between an espace fine and an espace mots pretty small, and when using a
fixed width font, use a normal espace for both. I know people, however,
who insist on the difference, and drop the espace fine, rather than use
a full space. (They're the exceptions, I think, but I've not done a
statistical analysis to prove it.)

In C, I've noticed that it is immediately obvious when a French speaker
has written the code, even if the comments are in English -- there's a
space in front of the : and the ;, which is never present in code
written by anyone else.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Nov 14 '05 #85
On 29 May 2004 11:42:44 +0200, in comp.lang.c , James Kanze
<ka***@gabi-soft.fr> wrote:
Da*****@cern.c h (Dan Pop) writes:

|> In <c9**********@o ravannahka.hels inki.fi> Joona I Palaste
|> <pa*****@cc.hel sinki.fi> writes:

|> >Now the French, they put a space before an exclamation or question
|> >mark. Like this: "Regardez moi ! Je suis français !". What's
|> >with that, then?

|> Yet another bogus generalisation coming from Joona. Quoting from a
|> post from a French mailing list:

|> ton enfant ? quel age?

Doubtlessly a typo. Or simply incorrect use.


The second is a typo. I work for a french bank, and the vast majority of
french expats use spaces before and after emphatic punctuation. Only the
anglicised french omit the space.

Remind me what this has to do with C....
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #86
In comp.lang.c C# Learner <cs****@learner .here> wrote:
Alex Moskalyuk wrote:
Have you ever looked into Perl or Lisp code?

C suddenly starts making perfect sense.

What's uneasy to you? Curly braces, parentheses, keywords, or something
else?
One of the biggest flaws in C syntax, in my opinion, is the required
parentheses for test conditions.

Here's a very simple example:

void Foo
{
if (FooBar(Parse(P rocess(GetInput ())))
DoSomething();
}

That is _very_ bad code. What if Parse, Process or GetInput fails,
how would you know what hit you?

Instead,
void Foo(void)
{
type_t a;
if(!(a=get_inpu t()))
puts("GetInput died");
if(!(a=process( a)))
puts("process died");
if(!(a=parse(pa rse())
puts("Parse died");
if(foobar(a)
do_something();
}
Imagine if, instead, we could write the following:

void Foo
{
if FooBar(Parse(Pr ocess(GetInput( ))):
DoSomething();
}
This is why: it would not be consistant with the C code-style. The
style is in fact is very obvious when properly idented and highligthed,
Another nicety about Python is the fact that whitespace is used for
defining code blocks. This makes code much clearer than the equivalent
C code, which requires block being/end markers.
I don't like the idea of having indentation as a part of the syntax,
very hard to write longer code on 80x25 terminals :-(
Even if one's accustomed to C syntax, the former is still clearer and
easier-to-read, don't you think?
Programming languages are not meant to be easy to read.
If you want easy-to-read, comment your code.
Why C? Why?!


Here's why: It works and is perfectly balanced between levels. It is not
gibberish like LISP or Assembly (no offense, but it is kinda hard to see what
(+ 2 (* 8 (expt 25 (/ 5 2)))) does). And you still consistent (unlike BASIC)
and doesent require you to write a smaller novel (unlike COBOL) to get your
app to do something. Python may be an OK language, but it still doesent
have the maturity of C.

--
Viktor Lofgren, Umea, Sweden
Mainly self-eductated UNIX programmer, running Slackware-current.
Nov 14 '05 #87
Viktor Lofgren wrote:
Learner <cs****@learner .here> wrote:
Alex Moskalyuk wrote:
Have you ever looked into Perl or Lisp code?

C suddenly starts making perfect sense.

What's uneasy to you? Curly braces, parentheses, keywords, or
something else?


One of the biggest flaws in C syntax, in my opinion, is the
required parentheses for test conditions.

Here's a very simple example:

void Foo
{
if (FooBar(Parse(P rocess(GetInput ())))
DoSomething();
}


That is _very_ bad code. What if Parse, Process or GetInput
fails, how would you know what hit you?

Instead,
void Foo(void)
{
type_t a;
if(!(a=get_inpu t()))
puts("GetInput died");
if(!(a=process( a)))
puts("process died");
if(!(a=parse(pa rse())
puts("Parse died");
if(foobar(a)
do_something();
}


That is still foul and faulty code. Assuming there is an error
value 0, try:

void Foo(void)
{
type_t a;

if (!(a = get_input())) puts("GetInput died");
else if (!(a = process(a))) puts("process died");
else if (!(a = parse(a()) puts("Parse died");
else if (foobar(a) do_something();
/* else donothing */
}

If there is no such error value, the original is much clearer.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!
Nov 14 '05 #88

On Sat, 29 May 2004, Viktor Lofgren wrote:

In comp.lang.c C# Learner <cs****@learner .here> wrote:

if (FooBar(Parse(P rocess(GetInput ())))
DoSomething();
That is _very_ bad code. What if Parse, Process or GetInput fails,
how would you know what hit you?


<on-topic for once> This is the general argument in favor of
writing fail-immune functions. For example, if 'GetInput' fails
it will (let's say) return NULL. Now, 'Process' knows that it
will be very tempting for the client to write 'Process(GetInp ut())';
thus, 'Process' codes as follows:

void *Process(const void *input)
{
if (input == NULL) return NULL;
[...]
}

Now 'Process' can handle anything 'GetInput' throws at it, and it
can do it in a reasonable manner. Apply the same solution to
'Parse' and 'FooBar'. Now the client can safely write

if (FooBar(Parse(P rocess(GetInput ())))
DoSomething();
else
/* Something went wrong in one of those four functions */
;

This is a nice idiom to learn and use; unfortunately, the C
standard library doesn't use it in most places. Especially in
'strcpy' it would be convenient, so that

#define stdup(s) (strcpy(malloc( strlen(s)+1), (s)))

wouldn't exhibit undefined behavior if 'malloc' were to fail,
but sensibly return NULL.
[Not that I'm advocating a change to 'strcpy'; just pointing
out one of the disadvantages of a model that *doesn't* use the
fail-immune handling shown above.]
<back off-topic>
I don't like the idea of having indentation as a part of the syntax,
very hard to write longer code on 80x25 terminals :-(


The canonical solution applies here: If your lines are too long
to be read comfortably by the average human, you ought to be writing
shorter lines. And/or smaller functions with fewer levels of
indentation.
Even if one's accustomed to C syntax, the former is still clearer and
easier-to-read, don't you think?


Programming languages are not meant to be easy to read.
If you want easy-to-read, comment your code.


Don't be ridiculous! Languages are *by definition* meant to make
communication simpler. And until computers learn to talk properly,
that communication is only going to happen through reading. C's
syntax, like that of every (non-joke) language in existence, was
designed to make reading and writing as easy, pleasurable and
effective as possible. The fact that some people like to write
impenetrable C code is no stranger than that some people like to
write impenetrable English or French.

-Arthur

Nov 14 '05 #89
On Wed, 26 May 2004 22:02:42 +0100, C# Learner <cs****@learner .here> wrote:
Why is C syntax so uneasy on the eye?

In its day, was it _really_ designed by snobby programmers to scare away
potential "n00bs"?
No, but the programmers who designed it didn't care about "n00bs";
their target audience was people who worked at Bell Labs. They were
all very very smart. And it was in the days where actually printing
programs and typing them in was physically expensive and difficult
(literal paper-oriented terminals and tty inputs). So severely
limiting characters was a desirable major goal then. It isn't now.
If so, and after 50+ years of programming research,
why are programming languages still being designed with C's syntax?
Profound anti-intellectualism among practitioners, and cargo-cult
imitation. This spurious idea being that "gee, C was popular; so why
don't we make our language with Cish syntax so we might be popular
too."

Yes, these things have been tested empirically (though that field
is woefully underfunded) and yes the answer comes back that other
syntaxes are less error prone.

In particular the Fortran 90 and Ada typical syntaxes come out on
top.
These questions drive me insane. Every waking minute...


The answers are easy. But depressing.
Nov 14 '05 #90

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

699
34347
by: mike420 | last post by:
I think everyone who used Python will agree that its syntax is the best thing going for it. It is very readable and easy for everyone to learn. But, Python does not a have very good macro capabilities, unfortunately. I'd like to know if it may be possible to add a powerful macro system to Python, while keeping its amazing syntax, and if it could be possible to add Pythonistic syntax to Lisp or Scheme, while keeping all of the...
22
3439
by: Tuang | last post by:
I'm checking out Python as a candidate for replacing Perl as my "Swiss Army knife" tool. The longer I can remember the syntax for performing a task, the more likely I am to use it on the spot if the need arises. If I have to go off and look it up, as I increasingly have to do with Perl's ever hairier syntax, I'm more likely to just skip it, making me even less likely to remember the syntax the next time. So I hear that Python is easier...
14
2320
by: Sandy Norton | last post by:
If we are going to be stuck with @decorators for 2.4, then how about using blocks and indentation to elminate repetition and increase readability: Example 1 --------- class Klass: def __init__(self, name):
16
2613
by: George Sakkis | last post by:
I'm sure there must have been a past thread about this topic but I don't know how to find it: How about extending the "for <X> in" syntax so that X can include default arguments ? This would be very useful for list/generator comprehensions, for example being able to write something like: instead of the less elegant explicit loop version that has to check for the length of each sequence. What do you think ? George
23
2544
by: Carter Smith | last post by:
http://www.icarusindie.com/Literature/ebooks/ Rather than advocating wasting money on expensive books for beginners, here's my collection of ebooks that have been made freely available on-line by their authors. There are lots of them out there but this selection cuts out the junk. If you know of any other good books that are freely available please post a link to them here and I'll consider adding them to the site.
19
2983
by: Nicolas Fleury | last post by:
Hi everyone, I would to know what do you think of this PEP. Any comment welcomed (even about English mistakes). PEP: XXX Title: Specialization Syntax Version: $Revision: 1.10 $ Last-Modified: $Date: 2003/09/22 04:51:49 $ Author: Nicolas Fleury <nidoizo at gmail.com> Status: Draft Type: Standards Track
4
3788
by: Jeremy Yallop | last post by:
Looking over some code I came across a line like this if isalnum((unsigned char)c) { which was accepted by the compiler without complaint. Should the compiler have issued a diagnostic in this case? (I think it's not required to, but I'd like confirmation). Jeremy.
4
7631
by: Bob hotmail.com> | last post by:
Everyone I have been spending weeks looking on the web for a good tutorial on how to use regular expressions and other methods to satisfy my craving for learning how to do FAST c-style syntax highlighting in C# but I have yet to find anything useful I know there are people at MS that know this stuff like the front of their hand and I know there are many people out on the web that are proficient in doing this as well but it seems nobody...
3
16257
by: Manuel | last post by:
I'm trying to compile glut 3.7.6 (dowbloaded from official site)using devc++. So I've imported the glut32.dsp into devc++, included manually some headers, and start to compile. It return a very strange error. In your experience, where I should looking to find the real error? Surely the sintax of glut is correct... gcc.exe -c glut_bitmap.c -o glut_bitmap.o -I"C:/Dev-Cpp/include" -I"../../include" -D__GNUWIN32__ -W -DWIN32 -DNDEBUG...
0
9811
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9657
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
1
10577
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9359
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
1
7774
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
6975
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5812
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4003
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3103
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.