Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #2659 > unrolled thread

programmer's keyboard

Back to article view | Back to comp.programming

Contents

  programmer's keyboard bob <bob@coolfone.comze.com> - 2012-12-26 11:45 -0800
    Re: programmer's keyboard Robert Wessel <robertwessel2@yahoo.com> - 2012-12-26 15:01 -0600
      Re: programmer's keyboard "BartC" <bc@freeuk.com> - 2012-12-26 21:36 +0000
        Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-26 21:12 -0600
        Re: programmer's keyboard Robert Wessel <robertwessel2@yahoo.com> - 2012-12-27 23:45 -0600
          Re: programmer's keyboard "BartC" <bc@freeuk.com> - 2012-12-28 13:46 +0000
            Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2012-12-29 11:42 +1300
            Re: programmer's keyboard "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-29 15:15 +0000
              Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-29 14:41 -0600
                Re: programmer's keyboard "BartC" <bc@freeuk.com> - 2012-12-29 21:10 +0000
                  Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-29 15:26 -0600
                    Re: programmer's keyboard "BartC" <bc@freeuk.com> - 2012-12-29 22:41 +0000
                      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 02:12 -0600
                        Re: programmer's keyboard "BartC" <bc@freeuk.com> - 2012-12-30 11:20 +0000
                          Re: programmer's keyboard malcolm.mclean5@btinternet.com - 2012-12-30 10:19 -0800
                            Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 14:51 -0600
                Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2012-12-30 10:43 +1300
                  Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 01:55 -0600
                    Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2012-12-30 21:06 +1300
                      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 02:35 -0600
                        Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2012-12-30 18:12 +0000
                          Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 13:30 -0600
                            Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2012-12-31 09:36 +1300
                              Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 17:27 -0600
                                Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2012-12-31 13:00 +1300
                                  Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-31 03:13 -0600
                                    version control (was: Re: programmer's keyboard) rugxulo@gmail.com - 2012-12-31 10:36 -0800
                                    Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2013-01-01 09:05 +1300
                                      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-31 16:58 -0600
                                        Re: programmer's keyboard Ian Collins <ian-news@hotmail.com> - 2013-01-01 13:24 +1300
                                    Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2013-01-02 12:23 +0000
                                      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2013-01-02 14:34 -0600
                                        Re: programmer's keyboard Robert Wessel <robertwessel2@yahoo.com> - 2013-01-02 15:35 -0600
                                          Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2013-01-03 13:19 -0600
                                        Re: programmer's keyboard Willem <willem@turtle.stack.nl> - 2013-01-03 08:35 +0000
                                          Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2013-01-03 13:46 -0600
                                        Re: programmer's keyboard rugxulo@gmail.com - 2013-01-03 00:52 -0800
                                        Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2013-01-03 15:00 +0000
                                Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2013-01-02 11:58 +0000
                                  Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2013-01-02 15:03 -0600
                                    Re: programmer's keyboard rugxulo@gmail.com - 2013-01-03 00:54 -0800
                                      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2013-01-03 13:06 -0600
                    Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2012-12-30 18:04 +0000
                      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-30 14:24 -0600
                        Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2013-01-02 11:34 +0000
            Writing Experimental Code "Aaron W. Hsu" <arcfide@sacrideo.us> - 2013-01-02 15:08 -0600
    Re: programmer's keyboard Rui Maciel <rui.maciel@gmail.com> - 2012-12-28 11:45 +0000
      Re: programmer's keyboard BGB <cr88192@hotmail.com> - 2012-12-28 12:29 -0600

Page 1 of 3  [1] 2 3  Next page →

#2659 — programmer's keyboard

Wouldn't it be nice if there was an official programmer's keyboard?  So you don't have to hit shift for curly braces or parentheses?  And ampersands, asterisks, and plus signs.  And quotes.  Have you guys seen anything like this?

[toc] | [next] | [standalone]

#2660

On Wed, 26 Dec 2012 11:45:02 -0800 (PST), bob <bob@coolfone.comze.com>
wrote:

>Wouldn't it be nice if there was an official programmer's keyboard?  So you don't 
>have to hit shift for curly braces or parentheses?  And ampersands, asterisks, 
>and plus signs.  And quotes.  Have you guys seen anything like this?


There are a variety of programmable keyboards, keyboards with extra
programmable keys, add-on keypads with programmable keys, etc. out
there.  Setting one of those up with your favorite characters on the
unshifted keys would be simple.  There are also a variety of
applications for remapping standard keyboards, you could, for example,
use one of those to put the desired keys on the numeric keypad.

OTOH, if your typing is so bad that your programming is actually being
slowed down by it (after all, the time required to type text in a
program is usually going to be quite small relative to the amount of
time taken to develop the program overall), learning to type would be
a better investment.

[toc] | [prev] | [next] | [standalone]

#2661

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message
news:o0omd8184k13mdl5j9d2pn0eta2a112hik@4ax.com...
> On Wed, 26 Dec 2012 11:45:02 -0800 (PST), bob <bob@coolfone.comze.com>
> wrote:
>
>>Wouldn't it be nice if there was an official programmer's keyboard?  So
>>you don't
>>have to hit shift for curly braces or parentheses?  And ampersands,
>>asterisks,
>>and plus signs.  And quotes.  Have you guys seen anything like this?

You could switch languages. Some have a lot less of this stuff. Or use
programmable function keys or something. But I would find a keyboard with
keys so that each symbol has a dedicated key, probably more difficult to use
than a regular one. And when you switch computers or use a laptop then
you'll be lost without that customised keyboard!

> OTOH, if your typing is so bad that your programming is actually being
> slowed down by it (after all, the time required to type text in a
> program is usually going to be quite small relative to the amount of
> time taken to develop the program overall), learning to type would be
> a better investment.

If your programming style is by trial and error, eg. with a rapid
development language, then languages that need a lot of fussy punctuation
can really slow you down. Also annoying are case-sensitive languages where
names have to be just right, so hbrBackground rather than hbrBackGround or
HBRbackground.

You shouldn't need to cross all the Ts and dot all the Is for a piece of
code that might be replaced by something else a few minutes later.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2662

On 12/26/2012 3:36 PM, BartC wrote:
 >
 >
 > "Robert Wessel" <robertwessel2@yahoo.com> wrote in message
 > news:o0omd8184k13mdl5j9d2pn0eta2a112hik@4ax.com...
 >> On Wed, 26 Dec 2012 11:45:02 -0800 (PST), bob <bob@coolfone.comze.com>
 >> wrote:
 >>
 >>> Wouldn't it be nice if there was an official programmer's keyboard?  So
 >>> you don't
 >>> have to hit shift for curly braces or parentheses?  And ampersands,
 >>> asterisks,
 >>> and plus signs.  And quotes.  Have you guys seen anything like this?
 >
 > You could switch languages. Some have a lot less of this stuff. Or use
 > programmable function keys or something. But I would find a keyboard with
 > keys so that each symbol has a dedicated key, probably more difficult to
 > use
 > than a regular one. And when you switch computers or use a laptop then
 > you'll be lost without that customised keyboard!
 >

I saw a show that did something to look sci-fi...
it took 3 black keyboards, and used black duct-tape to combine them 
(end-to-end) into a much bigger keyboard...

character then did keyboard actions like they were operating a piano.


funny would be if this could be followed by a person then using 2 mice 
at the same time:
2 mice for twice the point-and-click action.


well, never-mind using normal computer parts for props, and then using 
some big sci-fi looking thing, for what should have been a normal 
computer part... (in a post-apocalyptic setting, and someone asks for a 
hard drive, wouldn't it make sense to give them, well, a hard-drive...).

it is like, in a modern setting:
"hey man, I need to borrow your cell-phone", person is then handed a 
CB-radio with an analog-phone handset glued on, some blinking lights, 
and a "rabbit ears" TV antenna...


 >> OTOH, if your typing is so bad that your programming is actually being
 >> slowed down by it (after all, the time required to type text in a
 >> program is usually going to be quite small relative to the amount of
 >> time taken to develop the program overall), learning to type would be
 >> a better investment.
 >
 > If your programming style is by trial and error, eg. with a rapid
 > development language, then languages that need a lot of fussy punctuation
 > can really slow you down. Also annoying are case-sensitive languages 
where
 > names have to be just right, so hbrBackground rather than 
hbrBackGround or
 > HBRbackground.
 >
 > You shouldn't need to cross all the Ts and dot all the Is for a piece of
 > code that might be replaced by something else a few minutes later.
 >

granted, but it is usually a tradeoff:
less punctuation often means more keywords.

typically, for quickly typing things, punctuation is better than keywords.

granted, dunno about others, but typing code often involves having a 
finger semi-permanently within reach of SHIFT, typically with all the 
other fingers doing a keyboard dance to hit all the other characters.

it comes as a mystery if it would almost make sense to have shift as a 
sort of toggle (sort of like caps-lock but differently placed and 
"actually useful", in that it would behave more like a normal shift).

also maybe several additional keys which could be "similar" to the CTRL 
or ALT keys, mostly for sake of expanding the range of 
application-usable keyboard shortcuts. say, ALT2/ALT3, which could 
(functionally) take the place of the Windows and Menu keys, which are 
as-is pretty much useless, and would probably make more sense as modifiers.

as-is, the Windows key is basically something one hits accidentally and 
which breaks the flow of using another app by the start-menu popping up, 
whereas if it were a modifier (with no action on its own, and usable 
from apps), maybe it could actually be more useful for stuff...


or such...

[toc] | [prev] | [next] | [standalone]

#2665

On Wed, 26 Dec 2012 21:36:36 -0000, "BartC" <bc@freeuk.com> wrote:

>
>
>"Robert Wessel" <robertwessel2@yahoo.com> wrote in message
>news:o0omd8184k13mdl5j9d2pn0eta2a112hik@4ax.com...
>> On Wed, 26 Dec 2012 11:45:02 -0800 (PST), bob <bob@coolfone.comze.com>
>> wrote:
>>
>>>Wouldn't it be nice if there was an official programmer's keyboard?  So
>>>you don't
>>>have to hit shift for curly braces or parentheses?  And ampersands,
>>>asterisks,
>>>and plus signs.  And quotes.  Have you guys seen anything like this?
>
>You could switch languages. Some have a lot less of this stuff. Or use
>programmable function keys or something. But I would find a keyboard with
>keys so that each symbol has a dedicated key, probably more difficult to use
>than a regular one. And when you switch computers or use a laptop then
>you'll be lost without that customised keyboard!
>
>> OTOH, if your typing is so bad that your programming is actually being
>> slowed down by it (after all, the time required to type text in a
>> program is usually going to be quite small relative to the amount of
>> time taken to develop the program overall), learning to type would be
>> a better investment.
>
>If your programming style is by trial and error, eg. with a rapid
>development language, then languages that need a lot of fussy punctuation
>can really slow you down. Also annoying are case-sensitive languages where
>names have to be just right, so hbrBackground rather than hbrBackGround or
>HBRbackground.


I think many people would question such a programming style.  Trying
things randomly until something works is usually not a good way to
write reliable code.


>You shouldn't need to cross all the Ts and dot all the Is for a piece of
>code that might be replaced by something else a few minutes later.


Some attention to detail is expected in this profession.

[toc] | [prev] | [next] | [standalone]

#2667

"Robert Wessel" <robertwessel2@yahoo.com> wrote in message
news:cdcqd8htmmdm7l81imb6c3mn8cl33jcbj0@4ax.com...
> On Wed, 26 Dec 2012 21:36:36 -0000, "BartC" <bc@freeuk.com> wrote:

>>If your programming style is by trial and error, eg. with a rapid
>>development language, then languages that need a lot of fussy punctuation
>>can really slow you down.

> I think many people would question such a programming style.  Trying
> things randomly until something works is usually not a good way to
> write reliable code.

Do you never write experimental code? Or have code which doesn't work as
expected and you have to try several different approaches? Or have an
elusive bug and have to put in temporary debug code in lots of different
places?

(And I also like writing temporary code such as that in capitals. You can't
do that in a case-sensitive language (without creating duplicate upper-case
versions of keywords and identifiers).)

>>You shouldn't need to cross all the Ts and dot all the Is for a piece of
>>code that might be replaced by something else a few minutes later.
>
>
> Some attention to detail is expected in this profession.

Well, it reduces productivity. If I'm writing in C, and want to quickly
print out some data structure I've just filled in to make sure it's worked
properly, I might have to write something like this:

int i;

for (i=0; i<sizeof(A)/sizeof(A[0]); ++i)
  printf("%d: (%s %f %i)\n",i,A[i].s,A[i].f,A[i].i);

with a dozen things that have to be 'just so'. In another language, I might
just write:

 println A

Once the data is verified, there is no longer any need for those 10
parentheses, 8 square brackets, 4 percentage sizes, commas, etc or having to
write 'i' 7 times, etc. It's all wasted effort.

(OK, if you do need to write at the level of C, you might expect to have to
spell things out more. But I have a language that *is* at the same level as
C, and that same code would use less than half the number of punctuation
characters to express the same thing. Some languages are just too 'busy' 
with their syntax.)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2673

BartC wrote:
> "Robert Wessel" <robertwessel2@yahoo.com> wrote:
>>
>> Some attention to detail is expected in this profession.
>
> Well, it reduces productivity. If I'm writing in C, and want to quickly
> print out some data structure I've just filled in to make sure it's worked
> properly, I might have to write something like this:

If I want to make sure something works properly, I write a unit test. 
If I want to make sure my application does what the customer wants, I 
write rather a lot of them....

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2677

BartC wrote:

> (And I also like writing temporary code such as that in capitals. You
> can't do that in a case-sensitive language (without creating duplicate
> upper-case versions of keywords and identifiers).)

Then you're out of luck, if you're using a C-family language ;-)

I like to flag that kind of temporary code by indenting it to column 0.  Try 
it, you might like it.

(You can tell I'm not a Pythonista...)

    -- chris 

[toc] | [prev] | [next] | [standalone]

#2681

On 12/29/2012 9:15 AM, Chris Uppal wrote:
> BartC wrote:
>
>> (And I also like writing temporary code such as that in capitals. You
>> can't do that in a case-sensitive language (without creating duplicate
>> upper-case versions of keywords and identifiers).)
>
> Then you're out of luck, if you're using a C-family language ;-)
>
> I like to flag that kind of temporary code by indenting it to column 0.  Try
> it, you might like it.
>
> (You can tell I'm not a Pythonista...)
>

depending on language, it is often something like:
#if 1
or:
#if true
or:
if(true) { ... }
or similar...

this basically allows readily turning the code on or off, and indicates 
that it is probably temporary or experimental.

if code like this is disabled, and proves unlikely to be ever enabled 
again, it may later be removed.

if the code essentially becomes permanent and/or required, then the 
markers will (usually) eventually be removed.

[toc] | [prev] | [next] | [standalone]

#2682

"BGB" <cr88192@hotmail.com> wrote in message
news:kbnkla$k1b$1@news.albasani.net...
> On 12/29/2012 9:15 AM, Chris Uppal wrote:
>> BartC wrote:
>>
>>> (And I also like writing temporary code such as that in capitals. You
>>> can't do that in a case-sensitive language (without creating duplicate
>>> upper-case versions of keywords and identifiers).)
>>
>> Then you're out of luck, if you're using a C-family language ;-)
>>
>> I like to flag that kind of temporary code by indenting it to column 0.
>> Try
>> it, you might like it.

> depending on language, it is often something like:
> #if 1
> or:
> #if true
> or:
> if(true) { ... }
> or similar...
>
> this basically allows readily turning the code on or off, and indicates
> that it is probably temporary or experimental.

The #if options presumably bracket a bunch of lines between #if and #endif.
The trouble is those lines look like normal code! Unless the editor is
clever enough to highlight that section differently.

They are also more intrusive because are in addition to the debug code. 
(Also, they clash with the use of the same #if/#endif symbols for 
commenting out code, which is a different requirement; you might not want 
that code deleted when you come across it much later.)

The thing about writing in capitals, or using special indentation, is that
each line stands out by itself without relying on editing features.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2683

On 12/29/2012 3:10 PM, BartC wrote:
>
>
> "BGB" <cr88192@hotmail.com> wrote in message
> news:kbnkla$k1b$1@news.albasani.net...
>> On 12/29/2012 9:15 AM, Chris Uppal wrote:
>>> BartC wrote:
>>>
>>>> (And I also like writing temporary code such as that in capitals. You
>>>> can't do that in a case-sensitive language (without creating duplicate
>>>> upper-case versions of keywords and identifiers).)
>>>
>>> Then you're out of luck, if you're using a C-family language ;-)
>>>
>>> I like to flag that kind of temporary code by indenting it to column 0.
>>> Try
>>> it, you might like it.
>
>> depending on language, it is often something like:
>> #if 1
>> or:
>> #if true
>> or:
>> if(true) { ... }
>> or similar...
>>
>> this basically allows readily turning the code on or off, and indicates
>> that it is probably temporary or experimental.
>
> The #if options presumably bracket a bunch of lines between #if and #endif.
> The trouble is those lines look like normal code! Unless the editor is
> clever enough to highlight that section differently.
>

not usually an issue, and often the #if / #endif blocks may be fairly 
small (often a few lines).


> They are also more intrusive because are in addition to the debug code.
> (Also, they clash with the use of the same #if/#endif symbols for
> commenting out code, which is a different requirement; you might not
> want that code deleted when you come across it much later.)
>

usually, for comments, either // or /* ... */ is used.

/*
  * somePseudoCode();
  * morePseudoCode();
  *
  */


then:

#if 0
...
#endif

is not generally used for comments, but typically for either disabled 
code or test code.

if the distinction actually matters in a given situation, a person can 
just use "if(1) { ... }" or "if(true) { ... }" or similar, to similar 
effect.


> The thing about writing in capitals, or using special indentation, is that
> each line stands out by itself without relying on editing features.
>

but, OTOH, you can end up with unintended identifier clashes between 
symbols differing only in case.

it also fouls up naming conventions which rely on, say, "foo" and "Foo" 
being disjoint ("foo" for private members, "Foo" for public members), 
and the standard use of "FOO" for constant values.

[toc] | [prev] | [next] | [standalone]

#2688

"BGB" <cr88192@hotmail.com> wrote in message 
news:kbnnb5$q3r$1@news.albasani.net...
> On 12/29/2012 3:10 PM, BartC wrote:

>> (Also, they clash with the use of the same #if/#endif symbols for
>> commenting out code, which is a different requirement; you might not
>> want that code deleted when you come across it much later.)
>>
>
> usually, for comments, either // or /* ... */ is used.
>
> /*
>  * somePseudoCode();
>  * morePseudoCode();
>  *
>  */

Won't work in general because C /*...*/ comments don't nest. In fact when I 
argued the case for having nestable /*...*/ comments in comp.lang.c, I was 
advised to use #if for the purposes of commenting out code!

>> The thing about writing in capitals, or using special indentation, is 
>> that
>> each line stands out by itself without relying on editing features.
>>
>
> but, OTOH, you can end up with unintended identifier clashes between 
> symbols differing only in case.
>
> it also fouls up naming conventions which rely on, say, "foo" and "Foo" 
> being disjoint ("foo" for private members, "Foo" for public members), and 
> the standard use of "FOO" for constant values.

If the language is case-sensitive then you can't just switch to capitals 
anyway.

If the language doesn't care about case (such as all of mine), then those 
problems don't come up. (Except when interfacing to foreign functions where 
correct case is important, and then the name is only needs declaring 
properly once. The incidence of two foreign function names clashing when 
case is disregarded, is rare.)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2692

On 12/29/2012 4:41 PM, BartC wrote:
> "BGB" <cr88192@hotmail.com> wrote in message
> news:kbnnb5$q3r$1@news.albasani.net...
>> On 12/29/2012 3:10 PM, BartC wrote:
>
>>> (Also, they clash with the use of the same #if/#endif symbols for
>>> commenting out code, which is a different requirement; you might not
>>> want that code deleted when you come across it much later.)
>>>
>>
>> usually, for comments, either // or /* ... */ is used.
>>
>> /*
>>  * somePseudoCode();
>>  * morePseudoCode();
>>  *
>>  */
>
> Won't work in general because C /*...*/ comments don't nest. In fact
> when I argued the case for having nestable /*...*/ comments in
> comp.lang.c, I was advised to use #if for the purposes of commenting out
> code!
>

/* ...*/ nesting doesn't actually usually matter...


ironically, for actually commenting out lines of code, I generally use 
'//' comments.

usually, /* ... */ is for stuff that is *always* comments.

so:
//	CommentedLineOfCode();

/* Something said about code. */

/* ... */

would then only really be used in the case where any code is itself 
comment, as in the example, as non-functional pseudo-code (usually there 
only really to summarize the high-level intent).

block enabling/disabling code then comes back to #if or "if() {...}", 
where the choice as to which is used depends a fair amount on what the 
code is doing.


sometimes, it has ended up as:
if(FOO_DebugP(ctx))
{
	...
}

or similar, such as enabling debug prints or similar only if debugging 
is enabled for a given context.


>>> The thing about writing in capitals, or using special indentation, is
>>> that
>>> each line stands out by itself without relying on editing features.
>>>
>>
>> but, OTOH, you can end up with unintended identifier clashes between
>> symbols differing only in case.
>>
>> it also fouls up naming conventions which rely on, say, "foo" and
>> "Foo" being disjoint ("foo" for private members, "Foo" for public
>> members), and the standard use of "FOO" for constant values.
>
> If the language is case-sensitive then you can't just switch to capitals
> anyway.
>
> If the language doesn't care about case (such as all of mine), then
> those problems don't come up. (Except when interfacing to foreign
> functions where correct case is important, and then the name is only
> needs declaring properly once. The incidence of two foreign function
> names clashing when case is disregarded, is rare.)
>

most of my languages are case-sensitive.

to me, case sensitivity just "makes sense".

[toc] | [prev] | [next] | [standalone]

#2694

"BGB" <cr88192@hotmail.com> wrote in message
news:kbot6e$t1j$1@news.albasani.net...


> most of my languages are case-sensitive.
>
> to me, case sensitivity just "makes sense".

In the real world, things are generally case-insensitive. So I might be
Bart, bart or BART, without people thinking I am three different people (to 
say nothing of the other 13 variations).

Case is also ignored for email addresses and website names, and Google
searches (which would really make life difficult, if you had to try all
1000000 upper/lower case combinations of that 20-character search string,
and each one only matching hits using exactly the same combination).

Speech also doesn't really distinguish case.

For similar reasons, it can make life easier to forget about case in a
programming language, if you haven't got enough imagination to think up
different identifiers! (Besides, the first machines I used only had one
case.)

I know that a language might use case to emulate a different name-space, but
you surely don't need 2^N namespaces! (For each identifier of length N.) So
there might a 'case' for having just two (all-caps, and any other
combination).

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2697

On Sunday, December 30, 2012 11:20:30 AM UTC, Bart wrote:
> "BGB" <cr88192@hotmail.com> wrote in message
> 
> I know that a language might use case to emulate a different name-space, but
> you surely don't need 2^N namespaces! 
> 
My rule for C is that everything which depends on the standard library only
goes in lower case, anything that depends on an external library goes in 
mixed case, with the details influenced by that library (so everything that
depends on Qt gets the prefix QT, for example).

[toc] | [prev] | [next] | [standalone]

#2701

On 12/30/2012 12:19 PM, malcolm.mclean5@btinternet.com wrote:
> On Sunday, December 30, 2012 11:20:30 AM UTC, Bart wrote:
>> "BGB" <cr88192@hotmail.com> wrote in message
>>
>> I know that a language might use case to emulate a different name-space, but
>> you surely don't need 2^N namespaces!
>>
> My rule for C is that everything which depends on the standard library only
> goes in lower case, anything that depends on an external library goes in
> mixed case, with the details influenced by that library (so everything that
> depends on Qt gets the prefix QT, for example).
>
>

my usual conventions:
anything internal generally uses a naming scheme like:
LIBNAME_FuncName
or:
LIBNAME_Component_FuncName

these may be publicly accessible, but generally carry a disclaimer with 
their naming: subject to change without warning, or "use with caution".

this is often what most of the code in a library uses, mostly as this 
means there is no attempt being made for the library to hide its internals.


sometimes:
libname_component_funcname

but, this is essentially marking it private (it means: do not use).


public API functions then usually use:
libpfxFuncName();
or:
libpfxComponentFuncName();

some of the prefixes have been two-chars (like OpenGL), but most of my 
newer APIs use 3 or 4 characters for the prefix.

PfxComponentFuncName();

is possible, but isn't generally a form I have used.


these functions very often don't implement any real logic themselves, 
but more often simply redirect to the appropriate functions.

a partial exception to this rule is a library of mine that is actually 
fairly large, but consists almost entirely of runtime utility functions, 
many of which do implement logic.

some other libraries don't export any public API (generally, they leave 
their guts hanging out, and in a few cases, other libraries have wrapped 
them and provide a public API).

[toc] | [prev] | [next] | [standalone]

#2685

BGB wrote:
> On 12/29/2012 9:15 AM, Chris Uppal wrote:
>> BartC wrote:
>>
>>> (And I also like writing temporary code such as that in capitals. You
>>> can't do that in a case-sensitive language (without creating duplicate
>>> upper-case versions of keywords and identifiers).)
>>
>> Then you're out of luck, if you're using a C-family language ;-)
>>
>> I like to flag that kind of temporary code by indenting it to column 0.  Try
>> it, you might like it.
>>
>> (You can tell I'm not a Pythonista...)
>>
>
> depending on language, it is often something like:
> #if 1
> or:
> #if true
> or:
> if(true) { ... }
> or similar...
>
> this basically allows readily turning the code on or off, and indicates
> that it is probably temporary or experimental.

Independent of the language, just use your version control tool rather 
than muck about with conditional compiles.  Plenty of editors are 
version control and will mark or highlight code changes.

> if code like this is disabled, and proves unlikely to be ever enabled
> again, it may later be removed.

So just do a revert and its gone....

> if the code essentially becomes permanent and/or required, then the
> markers will (usually) eventually be removed.

...or check it in if you want to keep it.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2690

On 12/29/2012 3:43 PM, Ian Collins wrote:
> BGB wrote:
>> On 12/29/2012 9:15 AM, Chris Uppal wrote:
>>> BartC wrote:
>>>
>>>> (And I also like writing temporary code such as that in capitals. You
>>>> can't do that in a case-sensitive language (without creating duplicate
>>>> upper-case versions of keywords and identifiers).)
>>>
>>> Then you're out of luck, if you're using a C-family language ;-)
>>>
>>> I like to flag that kind of temporary code by indenting it to column
>>> 0.  Try
>>> it, you might like it.
>>>
>>> (You can tell I'm not a Pythonista...)
>>>
>>
>> depending on language, it is often something like:
>> #if 1
>> or:
>> #if true
>> or:
>> if(true) { ... }
>> or similar...
>>
>> this basically allows readily turning the code on or off, and indicates
>> that it is probably temporary or experimental.
>
> Independent of the language, just use your version control tool rather
> than muck about with conditional compiles.  Plenty of editors are
> version control and will mark or highlight code changes.
>
>> if code like this is disabled, and proves unlikely to be ever enabled
>> again, it may later be removed.
>
> So just do a revert and its gone....
>
>> if the code essentially becomes permanent and/or required, then the
>> markers will (usually) eventually be removed.
>
> ...or check it in if you want to keep it.
>


I don't really use version-control though.

most stuff that people would usually do via version control, I often end 
up doing via copying files/directories...

lame, I know, but this way is less effort...
and I am a lone developer anyways, so it doesn't really matter.

[toc] | [prev] | [next] | [standalone]

#2691

BGB wrote:
>
> I don't really use version-control though.

Then you should.  Modern SCM tools like mercurial or git are very simple 
to use for a stand alone developer.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#2693

On 12/30/2012 2:06 AM, Ian Collins wrote:
> BGB wrote:
>>
>> I don't really use version-control though.
>
> Then you should.  Modern SCM tools like mercurial or git are very simple
> to use for a stand alone developer.
>

last time I tried to use mercurial (and bitbucket), basically via the 
Windows Explorer plugin thinggy, it took absurdly long for it to try to 
synchronize or commit changes. for a roughly 5GB project, it would 
seemingly do single massive uploads/downloads (several GB at a time), 
and take a long time, and often fail.

with just myself working on it, it didn't really seem worthwhile.


with a local copy/paste, I can do the whole operation of copying 
source-trees around much quicker, even yes, if file-copying is still 
kind of slow sometimes...

and, if a person needs a copy on an external drive, they can copy/paste 
it to an external drive, and call it good enough...

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.programming

csiph-web