Programando às cegas: ambiente inicial para python, javascript, php e outras linguagens interpretadas

Salve, galera!

Muitas vezes me perguntam qual o setup que recomendo para quem está aprendendo a programar, começando por linguagens interpretadas como python ou javascript.

Então, segue o que eu recomendo. Essas recomendações são baseadas em bem mais do que opiniões pessoais, porém irei direto ao ponto, sem me justificar dos motivos de cada decisão.

Items necessários:

• Windows 10 ou 11
• NVDA
• Visual studio code

Acesso ao prompt de comandos

Para começo de conversa, sugiro fortemente que o Windows seja utilizado no início do aprendizado.

Dentro do Windows, você vai precisar aprender a utilizar a linha de comandos. Na verdade, utilizar o terminal (ou prompt de comandos) vai acabar sendo mais produtivo para quem não enxerga para uma série de coisas, por uma pancada de motivos.

Então, já que temos que aprender, vamos lá:

Configurações iniciais

Você precisará fazer isso apenas uma vez

1. Aperte Windows + r e digite cmd.
2. pressione alt + espaço para acessar os menus e selecione propriedades.
3. Na aba options (ou opções), habilite a caixa de verificação “enable ctrl key shortkuts” ou “habilitar atalhos com tecla ctrl”.
4. Habilite a caixa de verificação “use ctrl+shift+c / v as copy / past” ou “uusar ctrl + shift + c / v como copiar / colar”
5. Na aba terminal, selecione “Windows console host” na caixa combinada de “ddefault terminal application” ou “aplicação padrão de terminal”.
6. Pressione ok. Feche e abra novamente o prompt de comando, como instruído no primeiro item.

Navegando no prompt de comandos

Longe de mim aqui dar uma aula completa sobre terminal. Na dúvida, use o Google, você vai precisar fazer isso de qualquer forma.

Mas vamos a algumas dicas rápidas:

1. Toda vez que digitar um comando, o NVDA vai ecoar a resposta retornada automaticamente.
2. Setas para cima e para baixo navegam pelo histórico de comandos.
3. setas a esquerda e direita navegam pelo comando selecionado.
4. Enter manda o comando digitado para processar.
5. Se o retorno do comando for muito longo, talvez você não queira ouvir tudo. Nesse caso, é possível rever a tela com as teclas 7 8 9 (linha anterior, atual, próxima), 4 5 6 (palavra anterior, atual, próxima), 1 2 3 (caracter anterior, atual, próximo), tudo isso no teclado numérico com o num lock inativo para desktop. Se estiver usando layout de laptop, procure na documentação do NVDA ou leia nosso artigo sobre migração do JAWS para o NVDA.
6. Se esse modo for desconfortável, existe um complemento (também abordado no artigo sobre migração do JAWS) chamado “exploração virtual”. Instale e depois pressione ctrl + NVDA + w para rever a tela em um buffer.
7. A última coisa que o terminal sempre mostra, depois do resultado do comando, é a sua localização atual (em qual pasta ou diretório) você está nesse momento. Vai ser algo como c:\xxx\yyy\zzz. C: se refere ao seu drive principal, e a partir daí cada diretório é mostrado separado pela barra invertida ().

Então, faça uma experiência: simplesmente pressione enter. Você vai enviar nada para ser processado, vai receber nada como saída, e a única coisa que será exibida (e falada) vai ser essa última linha, mostrando o diretório no qual você está. A esta última linha, chamamos normalmente prompt.

Estabelecendo uma pasta de trabalho

HOME

Se para quem enxerga organização é desejável, para quem não enxerga é essencial, a menos que você queira ficar totalmente perdido com suas coisas. Isso ocorre porque você vai demorar muito mais tempo para se achar do que pessoas que enxergam, e isso vai te desgastar, o que queremos evitar, a final o aprendizado por si já é desgastante e portanto gostaríamos que outros desgastes fossem evitados neste momento.

Isto posto, talvez você não saiba, mas a maioria dos sistemas operacionais multi usuários (nos quais o Windows está incluso) oferece, para cada usuário, uma pasta particular, que chamaremos de home.

Sem a menor coincidência, quando você abre o prompt de comandos, sempre será posicionado dentro de sua pasta particular, a sua home.

Ali, recomendo a criação de uma pasta chamada projetos, e dentro de cada uma um projeto separado, mesmo que sejam chamados de exercicio1, exercicio2 ou similares.

Criando e acessando pastas

o comando md serve para criar pastas.

Se digitar “md projetos” e apertar enter, você ouvirá o prompt ser ecoado de volta, o que significa que o comando funcionou e não apresentou qualquer saída.

para comprovar que o diretório projetos foi criado, você agora pode entrar nele, com o comando cd. Se digitar “cd projetos” e apertar enter, você vai ouvir um novo prompt, agora te dizendo que você está dentro do diretório projetos.

Agora, dentro da pasta projetos, use o comando md para criaro diretório para seu primeiro projeto, e o comando cd para acessar essa pasta.

Diretórios especiais

Existem duas pastas especiais no sistema, chamadas respectivamente de “.” e “..”.

Essas pastas não existem de fato, seus nomes são atalhos. O diretório “.” se refere (ou resolve) para o nome do diretório onde você está atualmente. Pode parecer ridículo, mas vamos ver um exemplo de como usar isso a nosso favor em breve.

O diretório “..”, por outro lado, se refere ao diretório no o qual o diretório atual está contido, e pode ser usado para voltarmos na hierarquia de pastas.

Por exemplo: Se eu estiver em c:\marlon\projetos e fizer um “cd ..”, vou para c:\marlon. Se fizer novamente um “cd ..” vou para c:.

Bonus

Você pode abrir o Windows explorer diretamente na pasta onde está localizado no prompt de comandos. Para isso, digite “explorer .” e pressione enter.

Você notou o “.” no final do comando? Fazemos isso pois o comando explorer exige um parâmetro, que é o diretório inicial no qual ele deve abrir. E, no caso aqui, queremos que ele abra no diretório no qual estamos na linha de comando. E qual pasta especial sempre retorna o diretório em que estamos? Sim, a pasta “.”! Assim, ao passar . como um parâmetro para o comando explorer, fazemos com que este abra já na pasta onde estamos.

Obviamente, você pode criar as pastas via explorer, e depois acessar usando cd no prompt de comandos. Mas digitar md e o nome da pasta depois enter será na maioria das vezes mais rápido e eficiente do que usar a interface gráfica de qualquer maneira.

Linguagens interpretadas

Agora precisamos falar muito rapidamente sobre linguagens interpretadas. Nessas, caem, entre outras, python, javascript e php.

Falaremos sobre essas três que são mais populares, mas a maioria das outras segue o mesmo tipo de comportamento.

Porque são interpretadas?

Porque elas lêem arquivos e executam diretamente, não existe nenhum processo intermediário.

Em uma linguagem compilada (golang por exemplo), você:

1. Escreve o código em um arquivo com extenção .go.
2. Passa esse arquivo por um compilador.
3. O compilador (caso nenhum erro seja pego) gera um arquivo .exe (no Windows).
4. Você executa o arquivo .exe.

Veja que, nesse tipo de situação, o arquivo executado não é o mesmo arquivo do código fonte. Mas, em linguagens interpretadas, como exemplo aqui o javascript, você:

1. Escreve o código em um arquivo com extenção .js.
2. Chama o interpretador, passando o nome do arquivo a ser interpretado, algo como node (o nome do interpretador) e o nome do seu arquivo .js como parâmetro.
3. O interpretador (caso nenhum erro seja pego) interpreta e executa o arquivo.

Veja que, nesse caso, o arquivo executado (na verdade interpretado seria melhor) é exatamente o mesmo arquivo fonte que você escreveu.

Mas, querido autor, você deve estar se perguntando, eu uso o NVDA, que é escrito em python, e nunca instalei um interpretador python em meu computador. Mais do que isso, o arquivo inicial do nvda é um nvda.exe, o que prova que você não sabe o que fala. Você é um enganador. Você é um looser, um imbecil, um completo idiota e eu estou perdendo meu tempo!

Bom, querido leitor, quem sabe se eu posso ser uma ou mais dessas coisas. Isso pode ser discutido, mas o que está fora de discução aqui são esses argumentos. Se eu for tão lamentável assim, garanto, deve ser por outros motivos.

O que acontece, e você não sabia, é que junto com o NVDA vai um interpretador python inteirinho e que o arquivo nvda.exe inicia, por debaixo dos panos, um arquivo em bom e velho pythom que, sim, é interpretado.

Esses arquivos python também são compactados em um formato específico e descompactados em memória (muito resumidamente isso), portanto o acesso a eles acaba sendo mais rápido e sua distribuição mais compactada e segura.

Agora que minha credibilidade foi, espero, ao menos parcialmente restaurada, seguimos em frente.

REPL

Mas, se as linguagens interpretadas interpretam arquivos, elas também podem interpretar, vamos dizer assim, código escrito ao vivo por programadores?

Sim. A isso, chamamos de repl (read, evaluate, print, loop) ou (ler, interpretar, escrever, repetir).

Funciona assim: eu como programador não preciso escrever necessariamente um arquivo para experimentar com a linguagem. Em vez disso, posso pedir para a linguagem interpretar código que, em vez de estar em um arquivo, eu vou escrevendo.

1. Eu escrevo.
2. Aperto enter.
3. O interpretador interpreta o que eu escrevi.
4. O interpretador me diz o resultado daquilo (caso ele consiga interpretar).
5. E, finalmente, ele me pede por mais código, e o processo é repetido novamente.

O uso de repl’s é largamente desconhecido pela comunidade de programadores geral, menos ainda pela comunidade de programadores cegos, principalmente iniciantes.

A quantidade de tempo que se pode economizar simplesmente experimentando com código em vez de ir para o google buscar por alguma coisa ou escrever alguma função em algum arquivo qualquer do fonte e executar um fluxo enorme apenas para chegar no ponto de teste é enorme.

De fato, repl’s existem inclusive para algumas linguagens compiladas, notadamente java. Nesse caso, o repl primeiro faz uma pequena compilação e depois executa o código (isso muito resumidamente), mas nosso assunto aqui são linguagens interpretadas.

Instalação

Nesta altura, você já sabe, precisará instalar o interpretador da linguagem que você quer usar.

Instale o php, o node ou o python, e garanta que o caminho para o executável esteja na variável de ambiente PATH.

Certo, vamos precisar explicar este conceito.

A variável de ambiente PATH

Uma variável de ambiente é um recurso que os sistemas operacionais (Windows inclusive) oferecem para deixar a vida de todos mais fácil. Funciona assim: você configura a variável de ambiente em algum lugar que varia de sistema para sistema (painel de controles no caso do Windows), e toda vez que alguém precisa do seu valor, é só digitar o nome da variável e pronto, o valor é resolvido.

Mas porque essas variáveis existem?

para que você (ou software que você usa) consiga usar valores sem saber na verdade quem os configurou.

Por exemplo, um software pode querer decidir quantas threads usar, e isso é dependente do número de processadores. O que ele faz? Pede ao sistema o valor da variável “NUMBER_OF_PROCESSORS”. Quem configurou isso? Não interessa. Mas, em todas as máquinas com o Windows instalado, essa variável existirá, e apontará para o número de processadores do computador.

Um outro exemplo é a variável USERPROFILE. Esta aponta sempre para a home do usuário logado. Então o software rodando, se precisar ler ou escrever em arquivos na home do usuário, precisa apenas consultar a variável USERPROFILE, que terá um valor diferente dependendo do usuário logado (que está executando o software).

Assim, o software tem apenas uma instrução (do tipo leia o arquivo em %USERPROFILE%\applications\temp) e, dependendo do usuário que o executa, o valor retornado por essa variável será diferente, pois sempre apontará para a home do usuário logado.

você pode acessar qualquer variável de ambiente no prompt de comandos usando o comando echo. Faça echo %[nome_da_variável]%, por exemplo echo %USERPROFILE% e veja o que acontece.

Ainda melhor, para variáveis cujo valor é um caminho de diretórios, você pode usar seu valor com o comando cd. Por exemplo cd %USERPROFILE% sempre te levará para a sua home.

A variável PATH é utilizada para que comandos possam ser executados sem sabermos exatamente onde foram instalados.

Funciona dessa maneira: quando você digita um comando, por exemplo “node”, o sistema checa se um arquivo node.exe está na pasta em que você está. Se estiver, o arquivo é executado. De outra forma, antes de dizer que o arquivo não foi encontrado, o sistema lê o valor da variável de ambiente PATH. Esta, no Windows, apresenta uma série de diretórios separados por ponto e vírgula (;). O sistema tenta encontrar o arquivo solicitado em cada um dos diretórios ali listados e, caso encontre, o executa. Apenas retorna arquivo não encontrado se o arquivo não estiver em nenhum dos diretórios listados, além claro do diretório corrente.

E para que isso serve?

Serve para:

1. Que você possa, por exemplo, instalar o node na pasta que quiser. Porque, depois de instalado, a pasta onde o arquivo node.exe está será acrescentada na variável PATH, portanto você pode digitar “node” em qualquer lugar que o arquivo vai ser encontrado, independentemente de onde tenha sido instalado.
2. Que você possa executar um comando no diretório atual em vez de ter que descobrir onde ele está e ficar digitando o caminho sempre que precisar executar o comando.

Você precisa garantir que a pasta onde o executável do node ou do python ou do php está seja listada na variável PATH, para que possa executar confortavelmente os interpretadores na linha de comandos e para que outros editores, como o visual studio code, também possam fazer isso.

Normalmente, o node coloca a si próprio na variável PATH. O python oferece, como um dos passos da instalação, esta opção, e o php não faz isso, o que te obrigará a colocar manualmente a pasta de instalação na variável. Deixamos para você descobrir como fazer isso.

Executando os REPL’s

Para garantir que o intepretador de escolha esteja na variável de ambiente PATH, basta, em qualquer prompt de comando, digitar node ou python ou php -a e apertar enter. Se você cair no REPL (se não der arquivo não encontrado), está tudo certo com a configuração.

Agora, experimente um pouco com construções da linguagem que você precisa e se acostume ao REPL. Vai ser de muito valor.

Saindo

Para sair do REPL do node, pressione ctrl + d.

Para sair do REPL do python, digite ctrl + z e pressione enter.

Para sair do REPL do php, digite ctrl + c.

Demais configurações

Visual studio code

Na pasta do seu projeto, digite o comando “code .”.

Este comando, de maneira similar ao explorer, abre o visual studio code no diretório representado pelo seu parâmetro. Como passamos a pasta especial “.”, o Visual studio code abrirá na pasta atual, que é nesse caso o que queremos.

Extenções

Para python, você vai precisar das extenções python, pylance e python debugger, ambas publicadas pela Microsoft.

Para php, você vai precisar das extenções php intelephense publicada por Bem Mewburn e php debug, publicada por xdebug.

Para node, você não precisará de quaisquer extenções.

Cada uma dessas extenções precisa ser corretamente instalada, e está fora do escopo deste artigo detalhar os processos. No geral, lendo o readme de cada uma delas (exibido após a instalação) deverá ser suficiente.

Evite instalar extenções as quais você não precisa. Se não for desenvolver em php, não instale as extenções de php até que sejam necessárias, o mesmo se aplicando para as outras linguagens.

Independentemente de qual for a sua linguagem de desenvolvimento, você vai precisar da extenção indentnav, publicada por Tony Malykh. Tenha a certeza de que esta extenção está instalada.

NVDA

Precisaremos perparar o NVDA para suporte a desenvolvimento.

Configurações

Você deverá criar um perfil para programação. Se não souber como fazê-lo, procure documentação ou verifique o artigo sobre migração do JAWS para o NVDA que publicamos, onde os procedimentos estão detalhados.

Garanta que o perfil seja ativado com o carregamento do Visual Studio code.

No perfil:

1. Configure a pontuação para tudo.
2. Configure o anúncio de recuo de linha (identação) para som (recomendado) ou qualquer uma das outras opções, menos desligado.

Complementos

Você vai precisar do complemento Tony’s enhancements. Garanta que este complemento esteja instalado.

Executando

Agora, chegou a hora de rodar seus scripts.

1. Faça ctrl + n no visual studio code.
2. Faça ctrl + s para salvar o arquivo. Arquivos .php com a extenção .php. arquivos javascript com a extenção .js, arquivos python com a extenção .py. Salvar os arquivos com a extenção correta é importante pois ajuda o visual studio code a ativar as extenções corretas.
3. Escreva um código simples.
4. faça alt + tab para chegar na linha de comandos.
5. Digite node (ou python ou php) espaço e o nome do seu arquivo.
6. Ouça o retorno. Caso precise, use as teclas de cursor do NVDA para navegar pelo resultado.
7. Quando estiver satisfeito, escreva mais código.
8. Alt tab novamente para a linha de comandos, execute novamente. Para não precisar digitar node (ou python ou php) e o nome do seu arquivo, você pode apertar a seta para sima que te posicionará no último comando digitado e apenas pressionar enter.

Este fluxo deverá ser seguido e repetido para suportar o desenvolvimento, e se aproxima bastante da maneira que fazemos desenvolvimento profissional.

Bonus

Rever a saída com os cursores do NVDA ou com o complemento exploração virtual pode ser cançativo. Existe uma outra maneira, envolvendo redirecionamento de saída.

Mas, primeiro, um pouco de teoria.

E antes de você reclamar, se pretende se tornar um desenvolvedor e não quer saber como o que quer que esteja fazendo de fato funciona, considere se de fato você gostaria de ir por essa rota.

De qualquer maneira, seguimos em frente:

Todo software quando executa faz três coisas principais:

1. Lê entradas.
2. Processa entradas.
3. Escreve saídas.

O processador de textos recolhe entradas que você digita, processa (no sentido de formatar o texto entre outras tarefas) e escreve saídas (na tela, após cada letra e após o processamento, ao salvar um arquivo com o texto digitado, ao imprimir esses arquivos, entre outras coisas). Um navegador recolhe a entrada (ao digitar um endereço, ao clicar em um link, ao pressionar um botão), processa, e retorna a saída (ao construir a tela de acordo com o resultado do HTML obtido, entre outros). Um leitor de telas recolhe entrada (ao receber comandos e eventos do sistema operacional), processa as informações e escreve saída (ao falar o que está escrito na tela, entre outros).

Do ponto de vista do seu software, tudo (o que vem via teclado, o que vem via rede, o que vai para a tela, o que vai para a placa de som, o que vai para o hd) é abstraído para um conceito, o conceito de arquivos. O software lê entrada de um ou mais arquivos, processa informação, e escreve a saída em um ou mais arquivos.

Então, a tarefa do seu software é facilitada, pois ele na verdade precisa apenas saber:

1. Ler informações de arquivos.
2. Processar informação.
3. Escrever informações para um ou mais arquivos.

Cabe ao sistema operacional entender qual o tipo de arquivo está sendo lido ou escrito e ler ou escrever da maneira correta os conteúdos.

Mas o que isso tem que ver com a exploração de cursores do NVDA?

Cada arquivo (sendo uma tela, uma placa de som ou um arquivo na HD) é representado por um identificador numérico.

Não temos como saber qual identificador um sistema atribuirá a um arquivo em disco, por exemplo, antes de fazermos uma operação de open. Mas, alguns endereços são sempre constantes, e nós sabemos exatamente quais são.

Podemos, portanto, escrever para arquivos nesses endereços e sabemos sem sombra de dúvidas o que acontecerá.

Mas quais endereços são esses?

O standard output, descrito sempre pelo endereço 1 e o standard error, descrito sempre pelo endereço 2.

Quando você faz um console.log (no javascript), ou um print (no python) ou um echo (no php), está na verdade abrindo o arquivo no endereço 1, escrevendo conteúdo e fechando esse arquivo.

E o que o sistema operacional faz com conteúdo escrito no arquivo 1? Ele, por padrão, direciona para a tela.

Tanto o arquivo 1 como o arquivo 2 na verdade.

O arquivo 2 (standard error) é onde softwares (inclusive os interpretadores) escrevem saída de erro.

Mas aqui está o interessante: nós podemos, ao rodar um sofftware, informar ao sistema que, para esta execução, conteúdo escrito no arquivo 1 não deve ir para onde o sistema o mandaria, e sim para onde nós queremos.

Isso significa que o sistema pegará o que deveria ser escrito na tela (destino original do arquivo 1 ) e encaminhará para outro destino.

E qual destino nós queremos neste caso?

Um arquivo em disco, ao lado do nosso arquivo fonte. Particularmente costumo chamar esse arquivo sempre como a.txt

E como fazemos isso?

Simples: digitamos o comando (node ou python ou php) o nome do nosso arquivo fonte , um espaço, e o redirecionamento “> a.txt 2>&1”

Como isso funciona?

O prompt de comandos entende um > como o redirecionamento do arquivo 1 para algumn lugar. O lugar vem logo após, portanto “> a.txt” significa que o conteúdo do arquivo 1 que iria para a tela agora deve ser direcionado para o arquivo a.txt.

Se nosso software operar com sucesso, sua saída pode ser lida no arquivo a.txt.

O comando ctrl + shift + e permite navegar pelos arquivos dentro do visual studio code. Você pode muito facilmente, portanto, abrir o arquivo a.txt e analisar sua saída.

Mais do que isso, uma vez que o arquivo a.txt tenha sido aberto no vscode, você poderá alternar entre ele e o seu arquivo fonte com ctrl + tab, o que permite um acesso rápido a saída, com todo o conforto de ler em um editor de texto.

Mas, como estamos, se seu software estiver com erro, este erro será escrito na tela. Isso se deve ao fato de que o arquivo 2 (standard error), onde os erros são escritos, não foi redirecionado.

Para cuidar disso, após o “> a.txt”, que redireciona o standard output para o arquivo a.txt, colocamos 2>&1.

Este comando instrui que conteúdo escrito no arquivo 2 seja redirecionado para o arquivo 1. O arquivo 1 por sua vez está redirecionado para o arquivo a.txt.

Assim, garantimos que tando a saída correta (em caso de execução sem erros) quanto os erros (em caso de erros) sejam adequadamente redirecionados para o arquivo a.txt que poderá ser lido e analisado com extremo conforto.

Dicas

O processo acima descrito é muito eficiente, e pode ser utilizado para praticamente qualquer tipo de desenvolvimento, principalmente em linguagens interpretadas.

1. Codificar.
2. Alt tab, executar (comando completo da prineira vez, das outras apenas seta para cima e enter).
3. Se redirecionou os arquivos (o que recomendamos), ler a saída com calma no arquivo a.txt. Do contrário, ler na própria tela).
4. De volta no fonte, corrigir problemas ou continuar a codificar e repetir o processo.

Sempre:

1. Não codifique mais de uma funcionalidade ao mesmo tempo. Passos pequenos são a receita do sucesso.
   Se precisa ler do teclado e fazer um cálculo, primeiro aprenda a ler do teclado. Escreva a parte que lê do teclado e imprime o que foi lido na tela, até ter certeza de que funciona.
   Depois, escreva a parte de fazer o cálculo. Passe os parâmetros e garanta que os resultados do cálculo estejam corretos.
   Por fim, ligue o retorno do que foi lido do teclado com a função que faz o cálculo, e seu software estará pronto.
   Isso servirá para que, em caso de erro, a quantidade de lugares onde o erro possa ter sido causada seja pequena, o que facilitará sua análise.

Falando em erros …

Em caso de erro, leia calmamente o que está errado. Não finja que entende o que está escrito em inglês, se for o caso use um dicionário. Assumir incorretamente o que uma mensagem de erro diz vai te atrapalhar quando tentar ajustar o código, pois você muito provavelmente tentará arrumar algo diferente do que está sendo acusado como um erro.

A maioria dos interpretadores vai apontar uma linha do código fonte como o erro, e muitas vezes nesta linha de fato estará o que precisa ser ajustado, mas nem sempre.

Além disso, erros lógicos (em vez de erros de sintaxe ou de exceções) não serão apontados. Esses são detectados quando seu software faz algo diferente do esperado, e para entendê-los é necessário reler com atenção tudo o que foi escrito e entender onde o erro de lógica está.

Daí uma outra vantagem de se codificar por partes o que se deseja.

Identação

Essa palavra significa que código pertensente a um bloco começa mais a direita do que código fora deste bloco. Visualmente é importante e para python isso também faz parte da linguagem propriamente dita.

Se você configurou o visual studio code e o NVDA como sugerimos:

1. Ouvirá um tom cada vez que a identação mudar.
2. Se a identação for maior (código começa mais a direita), o som será mais agudo. Do contrário, o som será mais grave.
3. Podemos navegar entre linhas com a mesma identação usando alt + seta para cima e seta para baixo.
4. Em python, linhas terminadas em dois pontos (:) pedem que a próxima (ou próximas) linhas tenham identação maior, pois linhas terminadas em dois pontos (dois pontos) são aberturas de bloco.
5. Em python, um bloco termina quando a próxima linha começar em uma identação mais a esquerda (menor). Você precisará se atentar ao tom grave para entender quando um bloco terminou.
   A identação da próxima linha vai dizer a qual bloco ela pertense. Se você não se lembrar, poderá pressionar alt + seta para cima para ouvir a linha que abre o bloco que acabou de terminar.
6. Em javascript e php, um bloco começa normalmente em linhas que terminam com abre chave ({), e terminam com um fecha chave (}).
   Embora identação não seja parte da linguagem, é boa prática seguir as mesmas regras do python.
7. Pode parecer ruim, mas por exemplo se você não estiver interessado em uma determinada função (em python sempre, nas outras linguagens assumindo-se que o código esteja corretamente identado) é só pressionar alt + seta para baixo que você pulará a função inteira e irá para o seu final.
8. Isso vale para qualquer tipo de bloco.

Conclusão

Assim terminamos de descrever o que, em nosso ponto de vista, se configura a maneira mais eficiente de trabalharmos com código fonte de linguagem de programação quando não enxergamos.

Agradecendo sempre a Deus em primeiro lugar, também o fazemos a você, leitor, que chegou até o final deste artigo. Esperamos que isso possa ajudar e que tenham proveito.

© Copyright BlindTec 2024, todos os direitos reservados.
Para mais detalhes, consulte a página de direitos autorais do portal.